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1.0  EXECUTIVE  SUMMARY 


The  vision  of  the  Global  Information  Enterprise  (GIE)  is  to  move,  process,  manage,  and  protect 
the  C2ISR  information  that  supports  the  functions  of  Global  Awareness  and  Dynamic  Planning 
and  Execution.  The  mission  of  GIE  is  to  link  aerospace  assets  in-theater  and  globally,  to 
integrate  C2  &  ISR  networks,  to  defend  critical  information  systems  from  cyber  attack,  and  to 
develop  new  information  processing  and  management  techniques.  Most  large-scale  force  level 
simulations  assume  perfect  communications.  This  can  lead  to  significant  limitations  in  the 
results  obtained  from  running  these  simulations.  Tools  are  needed  to  bridge  these 
communications  modeling  gaps. 

The  GIESim  project  is  a  simulation  development  program  to  define,  design  and  implement  a 
Modeling  and  Simulation  (M&S)  framework  for  the  Global  Information  Enterprise  (GIE). 

Within  the  GIESim  framework  users  will  be  able  to  execute,  via  a  common  interface,  multiple 
communications  and  network  M&S  tools  to  most  effectively  and  efficiently  analyze  candidate 
communications  architectures  and  technologies.  The  GIESim  can  interface  with  other  M&S 
tools  (e.g.,  force-level  simulations  and  detailed  hardware  system  models)  to  provide  the 
appropriate  level  of  M&S  fidelity  and  processing  speed  for  the  broad  spectrum  of  M&S  tasks. 
The  GIESim  user  base  will  span  from  advanced  technology  researchers  to  communications 
network  architects  to  mission  planners. 

In  FY  2004,  the  GIESim  AFRL/IFGC  leadership  team  set  the  goal  of  expanding  on  and  drawing 
upon  the  expertise  and  lessons  learned  in  building  the  DTIG  Multi-Simulation  Demonstration 
(DMSD)  built  for  the  2003  SAB  Review.  In  FY04,  the  GIESim  capabilities  were  merged  into 
the  Joint  Semi- Automated  Forces  (JSAF)  simulation  in  AFRL  Rome  in  conjunction  with  the 
JSB-RD  team.  The  central  themes  for  the  FY04  GIESim/JSB-RD  merger  were: 

•  The  merger  of  the  GIESim/JSB-RD  software  to  add  communications  modeling  capabilities  to 
JSAF  by  interfacing  GIESim  JTIDS  modeling  capabilities.  JSAF  is  a  JFCOM  program  that 
is  used  extensively  for  war  gaming  and  large,  man-in-the  loop  exercises.  However,  JSAF 
does  not  include  any  communications  modeling,  and  simply  assumed  that  communications 
always  worked. 

•  Faster  and  Easier  design,  development  and  execution  of  GIESim  simulations. 

Maintenance  of  a  standing  version  of  the  GIESim  SAB  Demo  was  also  a  goal  for  FY04. 

This  work  resulted  in  the  successful  merger  of  GIESim/JSB-RD  software,  and  the  team  can  now 
demonstrate  the  addition  of  JTIDS  tactical  communications  to  JSAF  using  a  modified  version  of 
the  JTIDS  simulation  built  by  PSI.  With  the  advent  of  this  merger,  JSAF  now  has  tactical 
communications  to  support  critical  Network  Centric  Operations  (NCO)  and  Warfare  (NCW) 
needed  for  the  future  evolution  of  the  Joint  Enterprise  including  the  AF  C2  Constellation  Net, 
Army/USMC  LandWarNet,  and  the  Navy/USMC  FORCENet.  By  virtue  of  the  PSI  Link-16 
Network  Management  Tool  Suite  that  our  JTIDS  is  part  of,  JSAF  can  now  participate  in  network 
operational  planning  in  addition  to  tactical  operations  training  and  exercises. 
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2.0  INTRODUCTION 


This  final  report  reviews  the  work  done  by  PSI  in  FY04  for  AFRL  Rome,  NY.  Accompanying 
this  final  report  is  User  Simulation  Documentation  for  the  PSI  portion  of  the  GIESim/JSB-RD 
merger  software. 


2.1  Scope  of  Work 

The  scope  of  this  report  covers  three  GIESim  work  areas  in  FY04: 

1)  Integration  of  the  modifications  to  the  updated  GIESim  SAB  Demonstration.  This  was  a 
small,  though  significant,  effort  to  update  the  GIESim  SAB  Demo  that  was  built  in  FY03. 
The  effort  resulted  in  a  standing  demonstration  of  the  GIESim  capabilities  within  the 
AFRL  Rome  labs. 

2)  Preliminary  work  and  study  associated  with  potential  integration  of  the  GIESim  SAB 
Demo  with  the  DARPA/SAIC  NMS  and  OSC.  This  effort  was  never  funded,  and 
ultimately  dropped  at  the  direction  of  Jon  Valente. 

3)  The  merger  of  the  GIESim/JSB-RD  software.  This  is  the  most  substantial  and 
meaningful  work  that  was  completed  in  FY04,  and  is  the  primary  focus  of  this  final 
report. 


2.2  GEISim  SAB  Demo 

The  primary  requirement  for  the  GIESim  SAB  Demo  was  to  maintain  a  version  in  the  GIESim 
Lab  that  could  be  demonstrated  on  short  notice.  This  demo  was  to  use  a  new  driver  from  SAIC 
as  a  substitute  for  the  JBISim  component.  The  basic  functionality  for  the  SAB  Demo  needed  to 
be  retained.  Ultimately  the  team  agreed  to  the  move  to  RTI-S.  In  addition,  PSI  recommended 
the  migration  to  a  newer  version  of  the  underlying  JTIDS  simulation  and  a  newer  version  of 
GSS.  Both  changes  enabled  better  on-going  support  for  the  GEISim  SAB  Demo,  and  more 
flexibility  if  AFRL  decided  that  additional  features  were  needed  in  the  Demo. 


2.3  NMS  Integration  Exploration 

The  FY03  GIESim  SAB  Demo  was  quite  successful.  After  some  reflection,  the  AFRL  GIESim 
leadership  felt  that  additional  instrumentation  might  help  the  demo,  and  thought  that  the  demo 
might  benefit  from  a  more  centralized  control  interface.  Therefore,  the  GIESim  team  was  asked 
to  explore  integration  with  the  Network  Management  System  (NMS)  and  Online  Simulation  and 
Control  (OSC)  functionality  based  on  work  done  by  DARPA  and  SAIC.  NMS  and  OCS 
provided  C-based  APIs  for  monitoring  distributed  simulations  and  for  controlling  their  start-up 
and  shut  down.  The  GIESim  team  determined  that  additional  funding  was  required  to  support 
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this  effort,  and  ultimately  Jon  Valente  requested  that  all  further  work  stop  on  integration  with 
NMS  and  OSC. 


2.4  GIESim/JSB-RD  Software  Merger 

The  primary  effort  and  top  priority  for  GIESim  in  FY04  became  the  merger  of  GIESim  and  JSB- 
RD  software,  with  the  primary  goal  of  adding  Link- 16  communications  support  to  JSAF.  JSAF 
(Joint  Semi-Automated  Forces)  is  a  large  and  important  simulation  under  Joint  Forces  Command 
(JFCOM).  The  JSB-RD  has  their  own  branch  of  JSAF  in  Rome  for  the  purposes  of  adding  Air 
Force  behaviors  to  JSAF.  JSAF  is  used  for  frequent  war-gaming  exercises,  however,  JSAF 
currently  does  not  model  communications  -  communications  “simply”  happens.  The  GIESim 
Leadership  saw  a  great  opportunity  for  applying  the  capabilities  of  GIESim  to  JSAF.  The 
majority  of  this  final  report  is  focused  on  the  GIESim/JSB-RD  software  merger. 

It  is  important  to  note  that  the  PSI  Link- 16  Network  Management  System  shown  in  Figure  1 
was,  and  continues  to  be,  critically  important  to  the  success  of  the  GIESim/JSB-RD  software 
merger.  The  Link- 16  Planning  Tool  was  used  to  define  all  the  scenarios  and  Link- 16  Networks 
used  in  the  merger,  and  a  modified  version  of  the  Link-16/JTIDS  Simulation  was  the  tactical 
communications  component  that  we  added  to  JSAF. 


PSI  Link-1 6/JTIDS  Network  Management  System 


Figure  1  -  PSI  Link-16  Network  Management  System 


3.0  UPDATED  GIESIM  SAB  DEMO 


3.1  Requirements 

The  primary  requirements  for  the  GIESim  SAB  Demo  in  FY04  were  as  follows: 

1 .  Update  the  GIESim  SAB  Demo  so  that  it  could  be  maintained  and  would  be  available  at 
any  time  for  demonstration. 

2.  Move  to  RTI-S.  While  this  was  not  an  initial  requirement,  since  the  PSI  JTIDS 
simulation  was  moving  to  RTI-S  (since  JSAF  uses  RTI-S  versus  DMSO  RTI NG),  the 
team  chose  to  go  with  RTI-S.  Also,  since  RTI-S  does  not  use  a  centralized  RTI  server, 
there  is  one  less  component  to  start,  therefore  RTI-S  it  simplifies  the  demo. 

3.  Test  with  new  driver  from  SAIC  that  replaces  JBISim. 

4.  Retain  the  physical  structure  and  scenario  for  the  demo. 

All  of  these  requirements  were  met,  and  the  fully  operational  demo  was  installed  in  the  GIESim 
Lab  in  Rome.  The  sections  that  follow,  describe  the  design,  developments,  and  testing  that  were 
accomplished  to  meet  the  above  requirements. 


3.2  Changes  to  the  GIESim  SAB  Demo  Design 

The  primary  design  changes  to  the  PSI  simulation  components  in  the  GIESim  SAB  Demo  were: 

1.  Move  to  RTI-S 

2.  Upgrade  of  JTIDS  to  the  newer  version  available 

3.  Upgrade  JTIDS  and  SATCOM  to  the  most  recent  release  of  GSS  (Release  10.3.7). 

In  addition,  these  design  changes  preserved  the  SAB  Demo  functionality  including 
interoperability  with  STK  5.0,  and  interworking  with  the  new  GIESim  driver  tool  that  replaced 
the  JBISim  component  of  the  demo. 

Furthermore,  to  support  testing,  the  PSI  GIESim  HLA  TEST  DRV  was  also  moved  to  RTI-S 
and  the  newest  version  of  GSS. 
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3.3  PSI  Developments  for  GIESim  SAB  Demo 


Developments  associated  with  maintaining  the  GIESim  SAB  Demo  are  covered  in  this  section. 
Figure  2  shows  the  new  architecture  for  the  Demo.  The  primary  change  is  the  use  of  RTI-S 
rather  than  the  DMSO  RTI.  This  change  eliminated  the  centralized  DMSO  RTI  server. 


Figure  2  -  New  Architecture  of  GIESim  SAB  Demo 


3.3.1  Migration  to  Newer  Version  of  GSS 

The  GSS  JTIDS  and  GSS  SATCOMM  components  of  the  GIESim  SAB  Demo  were  migrated 
to  Version  10.3.7  of  GSS.  All  processes  and  resources  of  each  simulation  were  re-prepared  with 
the  new  version  of  GSS,  and  then  each  simulation  was  prepared. 

PSI  has  an  agreement  to  migrate  the  GIESim  SAB  Demo  to  newer  versions  of  GSS  when  they 
become  available.  Release  10.3.7  of  GSS  supports  enhanced  2D  and  3D  visualization.  Both  PSI 
and  GIESim  ordered  and  installed  newer  graphics  cards  to  use  this  capability. 


3.3.2  Migration  to  Newer  Version  of  JTIDS 

The  GIESIMINTERFACES  model  that  was  developed  for  the  GIESim  SAB  Demo,  see  Figure 
3,  provides  the  HLA  interface  to  the  other  HLA  connected  GIESim  SAB  Demo  simulation 
components,  the  TCP/IP  interface  to  the  GSS  SAT  COM  simulation,  and  the  AOC  and  SAT 
Gateways  used  for  transporting  the  demo  images  through  JTIDS.  The  GIESIM  INTERFACES 
model  was  exported  from  the  earlier  version  of  JTIDS  that  was  used  for  the  Demo,  and  was  then 
imported  into  the  latest,  more  capable  version  of  the  JTIDS.  After  import,  the  appropriate 
process  and  resource  changes  were  made  to  JTIDS,  and  the  GIESim  specific  icons  were  added  to 
functionally  incorporate  the  GIESim  SAB  Demo  functions.  Finally  the  Control  Specification  of 
the  newer  JTIDS  was  modified  to  activate  the  GIESim  Demo  components. 
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Figure  3  -  GIESim  SAB  Demo  Model 


3.3.3  Migration  to  RTI-S 

Once  GSS  had  been  modified  to  support  RTI-S,  migration  of  the  GIESim  SAB  Demo  to  RTI-S 
was  relatively  easy.  See  Section  5.6.1  of  this  report  for  further  details  on  migration  to  RTI-S. 


3.3.3.1  TEST  DRV 


The  first  step  in  the  migration  to  RTI-S  was  to  convert  the  PSI  HLA  TESTDRV  program  to 
RTI-S.  This  involved  re-preparing  it  with  the  version  of  GSS  that  was  modified  to  support  RTI- 
S.  The  default  RTI-S  rid  file  replaced  the  rid  file  that  was  used  with  the  DMSO  RTI. 

3.3. 3.2  JTIDS  and  SAT  COM 


The  steps  that  were  used  to  migrate  JTIDS  and  SATCOM  were  exactly  the  same  for  the 
TEST  DRV  program.  Also,  since  the  other  GIESim  SAB  Demo  simulation  components  used 
the  FOM  that  is  generated  by  GSS  for  JTIDS  and  SAT  COM,  the  FOM  did  not  need  to  change, 
and  the  existing  GIESIM.fed  file  could  simply  be  re-used. 

Figure  4  shows  a  picture  of  the  PSI  simulation  components  for  the  GIESim  SAB  Demo.  Note 
we  have  retained  the  existing  functionality  throughout  the  migration  to  RTI-S  and  to  a  newer 
version  of  JTIDS.  Note  that  RTI-S  appears  to  start  faster,  and  is  far  more  robust  to  federates 
leaving  the  federation  abnormally. 
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Figure  4  -  PSI  Simulation  Components  for  GIESim  SAB  Demo 


3.4  GEISim  SAB  Demo  Testing 

The  updated  PSI  components  for  the  GIESim  SAB  Demo  were  tested  in-house  using  several  PCs 
as  shown  in  Figure  5.  Proper  operation  was  verified  by  first  sending  messages  into  JTIDS  over 
HLA,  and  then  by  following  successful  transmission  through  JTIDS,  and  message  flow  into  and 
through  the  SATCOM  simulation.  Successful  message  transmission  was  also  verified  in  the 
opposite  direction  -  from  HLA  into  SAT  COM,  through  SAT  COM  into  JTIDS  and  then 
through  JTIDS  ultimately  resulting  in  a  new  HLA  message  coming  out  of  JTIDS. 

Over  August  18th  and  19th,  PSI  installed  a  new  version  of  GSS  and  upgraded  versions  of  JTIDS, 
SAT  COM  and  TESTDRV  that  use  RTI-S  in  both  the  JSAF  and  GIESim  labs.  In  both  labs, 
operation  was  successfully  verified  between  simulations  and  with  STK  by  using  our  HLA  test 
driver  TEST_DRV.  In  the  JSAF  lab,  our  simulation  components  were  also  successfully  tested 
with  the  new  test  driver  built  by  SAIC  for  the  upgraded  GIESim  SAB  Demo. 
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The  architecture  of  the  new  GIESim  SAB  Demo,  which  was  our  test  configuration,  is  shown  in 
Figure  2 

Tom  Parisi  of  the  AFRL  GIESim  team  was  given  training  on  the  upgraded  GIESim  SAB  Demo, 
and  Tom  expressed  his  satisfaction  with  the  updated  components. 

The  updated  GIESim  SAB  Demo  is  stable  and  in  a  form  that  is  much  more  easily  maintained. 
Mostly  importantly  the  GIESim  SAB  Demo  is  ready  to  demonstrate  at  any  time. 


PSI  GIESim  Test  Configuration 


PCI  PC2  PC3  PC4 


Figure  5  -  PSI  GIESim  In-House  Test  Configuration 
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4.0  EXPLORATION  OF  NMS/OSC  INTEGRATION 


Two  interests  of  the  GIESim  AFRL  leadership  drove  this  exploratory  work: 

1.  The  desire  to  have  central  control  of  the  GIESim  SAB  Demo. 

2.  The  desire  to  have  additional  monitoring  of  the  performance  of  the  GIESim  SAB  Demo. 

Central  control  was  a  potential  need  in  light  of  the  somewhat  complex  start-up  sequence  of  the 
original  GIESim  SAB  Demo  as  shown  in  Figure  6.  PSI  developed  Figure  6  and  shared  this  with 
the  team  and  with  the  SAIC  representative,  Gary  Warren,  in  discussions  on  NMS  and  OSC. 


Figure  6  -  GIESim  SAB  Demo  Start-up  Sequence 


In  May  04,  PSI  reviewed  several  sets  of  materials  on  the  NMS  and  Online  Simulation  and 
Control  (OSC)  work  that  SAIC  did  for  DARPA.  This  material  included  descriptions  of  the  SAIC 
Real-Time  Network  Monitoring  functions.  PSI  formulated  initial  impressions  -  particularly  on 
Remote  Start  and  Monitoring  functions  -  and  identified  the  need  for  additional  technical 
information  to  determine  stronger  applicability  to  GIESim  and  to  size  the  effort.  Later  in  May, 
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PSI  received  and  reviewed  a  draft  proposal  from  SAIC  on  GIESim  that  was  targeted  for  DARPA 
funding.  The  proposal  also  raised  several  questions  about  the  relationship  of  the  SAIC/DARPA 
work  to  the  parallel  work  with  JSAF,  and  also  further  raised  the  need  for  additional  technical 
details  to  size  the  work.  Furthermore,  the  presentation  material  that  had  been  received  earlier 
helped  PSI  formulate  some  earlier  impact  statements.  These  were  included  in  our  response  to 
Jon  Valente.  For  example,  the  OSC  remote  start  capability  requires  either  command  line 
arguments  or  an  initialization  file  to  start  a  simulation.  The  JTIDS  simulation  used  in  the 
GIESim  SAB  Demo  presents  three  GUI  panels  for  user  choices  on  start-up.  These  panels  will 
need  to  be  replaced  with  a  file  initialization  capability. 

In  late  May  the  team  received  the  User’s  Manual  for  Version  2.5  of  the  OSC  Framework.  The 
manual  provided  a  lot  of  useful  information  and  generated  several  questions  relative  to  GIESim. 
PSI  identified  the  need  for  a  technical  discussion  to  clarify  how  GIESim  and  OSC  would  best  fit 
together.  Part  of  this  discussion  would  compare  the  current  GIESim  architecture  and  networking 
with  respect  to  OSC  needs  and  capabilities. 

On  June  2  PSI  took  part  in  a  conference  call  that  took  place  between  AFRL,  SAIC  and  DARPA. 
The  purpose  of  the  conference  call  was  to  review  the  proposed  technical  transition  plan  for 
applying  the  SAIC  components  that  were  generated  for  DARPA  to  GIESim.  There  was  general 
agreement  to  couple  the  OSC  Framework  and  Network  QoS  Monitoring  with  GIESim 
components.  The  team  also  agreed  to  explore  the  possible  addition  of  the  SAIC/DARPA  JTRS 
model  to  the  GIESim  Framework. 

PSI  conducted  a  further,  deeper  review  of  the  User’s  Manual  for  the  OSC  Framework,  and 
formulated  a  number  of  insights  into  potential  modifications  needed  to  the  PSI  JTIDS  and 
SAT  COM  simulation  components  in  the  GIESim  SAB  Demo.  This  review  also  helped  us 
prepare  for  the  meeting  between  the  GIESim  team  and  SAIC  held  on  June  9. 

In  preparation  for  the  planned  June  9  meetings  with  SAIC  on  OSC  and  with  the  JSB-RD  team 
for  JSAF,  PSI  took  the  initiative  to  prepare  a  series  of  viewgraphs  to  overview  the  GIESim  SAB 
Demo  scenario,  the  demo  architecture,  the  demo  start-up  sequence,  and  GSS-based  GIESim 
components  provided  by  PSI.  These  slides  proved  to  be  very  useful  in  focusing  discussion  in  the 
meetings. 

PSI  participated  in  this  meeting,  and  used  our  overview  slides  to  provide  some  background  on 
the  GIESim  SAB  Demo  to  Gary  Warren  from  SAIC.  Based  on  these  slides  and  other  material 
presented  at  the  meeting  SAIC  developed  a  better  understanding  of  the  GIESim  SAB  Demo. 

The  scenario  overview,  Figure  7,  helped  SAIC  understand  the  conceptual  operation  and  purpose 
of  the  demo  scenario.  The  Physical  Architecture,  see  Figure  2,  of  the  Demo  helped  in 
delineating  all  the  simulation  components,  their  functional  roles,  and  their  simulation  network 
connectivity  by  virtue  of  HLA  and  TCP/IP  sockets.  This  view  also  showed  all  the  components 
that  the  OSC  remote  start  capabilities  would  need  to  “manage”. 


10 


Figure  7  -  GIESim  SAB  Demo  Scenario  Overview 


The  start-up  sequence,  Figure  6,  showed  the  dependencies  between  the  GIESim  multi-simulation 
components,  including  points  where  simulations  were  waiting  for  user  inputs  to  GUIs,  and  were 
waiting  for  connections  from  other  simulations.  This  particular  slide  was  highly  useful  in 
focusing  the  meeting,  and  the  team  reviewed  the  slide  line  by  line  to  understand  the  sequence 
and  what  was  going  on  behind  the  scenes.  This  slide  helped  to  identify  and  capture  information 
that  was  needed  to  support  the  demo  components,  e.g.,  IP  addresses  and  ports,  location  of  DTED 
and  contour  files,  and  needed  changes  to  the  user  interfaces  and  file  and  directory  structures  of 
the  GIESim  components  to  permit  OSC  to  handle  remote  start  and  shut-down. 

The  final  slide,  Figure  8,  illustrated  some  of  the  file  interfaces  on  the  JTIDS  and  SAT_COM 
simulations  provided  by  PSI,  and  served  to  stimulate  additional  discussions. 

At  this  time,  the  GIESim  team  ultimately  concluded,  partly  based  on  inputs  from  PSI,  to  retain 
the  functional  behavior  and  scenario  of  the  GIESim  SAB  Demo  while  applying  the  OSC 
Framework  to  automate  the  remote  start/stop  of  the  Demo,  and  to  add  in  the  SAIC  Network  QoS 
Monitoring  functions  to  the  current  set  of  GIESim  simulations.  PSI  viewed  this  as  a  wise 
decision  since  it  retains  the  current  scenario  that  took  a  long  time  to  define,  and  since  it 
minimizes  the  number  of  changes  needed  to  work  with  OSC  and  the  Network  QoS  Monitoring. 
The  team  also  agreed  to  explore  the  addition  of  the  SAIC/DARPA  JTRS  model  into  the  GIESim 
Framework  and  scenario,  as  a  second  step  in  working  with  SAIC  following  completion  of  the 
OSC  work. 

On  mid- June,  PSI  received  some  details  and  files  associated  with  the  software  for  the  OSC 
Framework  and  for  the  API  for  the  Network  QoS  Monitor.  It  rapidly  became  clear  that  a 
Windows  based  (versus  Linux-based)  library  was  needed  to  support  the  API.  This  fact  was 
communicated  to  SAIC  and  to  the  GIESim  team.  The  team  received  a  commitment  from  SAIC 
to  build  and  provide  a  Windows  library  for  the  QoS  API.  Review  of  the  header  files,  example  of 
the  API  calls,  and  file  structure  required  for  the  OSC  remote  start/stop  helped  PSI  to  size  the 
work  effort  required  to  support  these  functions. 

On  June  15  PSI  received  a  request  from  Jon  Valente,  AFRL,  to  provide  a  statement  of  work 
(SOW)  and  costs  for  modifying  the  JTIDS  and  SAT_COM  simulations  to  work  with  the  OSC 
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remote  start/stop  and  to  support  the  QoS  API,  and  to  add  the  SAIC/DARPA  JTRS  model  to  the 
GIESim  Demo  scenario.  PSI  provided  the  SOW  on  June  15  and  our  cost  statement  on  June  16. 

In  July,  PSI  and  the  other  GIESim  team  members  received  direction  from  Jon  Valente  to  stop  all 
work  on  the  integration  of  GIESim  components  with  the  SAIC/DARPA  OCS  APIs. 


Figure  8  -  PSI  GIESim  Simulation  Components  and  Interfaces 
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5.0  GIESIM/JSB-RD  MERGER 


This  section  of  the  Final  Report  describes  the  work  PSI  undertook  and  the  accomplishments 
completed  with  respect  to  the  GIESim/JSB-RD  software  merger. 


5.1  Merger  Requirements 

Figure  9  shows  the  steps  that  PSI  and  the  GIESim/JSB-RD  team  took  in  merging  the  GIESim 
and  JSB-RD  software.  This  diagram  was  created  by  PSI  to  assist  the  team  maintaining  focus  on 
the  steps  that  we  had  to  follow.  The  merger  requirements  were  determined  over  several  meetings 
and  email  exchanges.  In  most  cases,  PSI  encouraged  a  Keep-It-Simple  (KIS)  approach.  The 
sections  that  follow  in  this  report  largely  follow  the  sequence  in  this  diagram. 


Simulation  Players  Simulation  Entities  HLA  Com  Hooks 

-  Roles/Responsibilities  -  Behaviors  by  Sim  Com  Strategies 

Physical  Interfaces  Coupling  bt.  Sims  Interfaces 


Force  Deployment(s) 
Movement  Paths 
Mission  Goals 


JTIDS  Networks 
Other  Networks 


Interoperability  Tests 
Metrics  Analysis 
Demo 


Figure  9  -  Steps  for  GIESim/JSB-RD  Software  Merger 


Early  in  the  program  PSI  produced  a  white  paper  entitled  “Technical  Considerations  for 
GIESim-JSAF  Merger”  that  was  formative  in  mapping  out  many  of  the  considerations  and 
recommendations  that  were  later  used  in  the  merger.  The  paper  provided  background  material 
on  JTIDS  and  Link- 16  that  were  intended  to  aid  the  team  in  understanding  tactical 
communications  better,  particularly  the  Link- 16  message  set  and  addressing  capabilities.  Figure 
9  first  presented  in  this  paper. 
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Figure  10  shows  the  various  architectural  layers  that  were  considered  when  building 
requirements  for  the  GIESim-JSAF  communications  scenario  and  subsequent  simulation 
enhancements. 


Dynamic  Mission  Events 

Trigger  the  Flow  of  Mission  Thread 
Comm 

At  Specific  Times/Places 
E.g.,  Pop-up  Threats 


Mission  Threads 

Define  Flow  of  Comm  Messages 
Associated  with  a  particular  Mission 
Threads  consist  of  multiple  Links 
Example  Threads:  TCT  and 
SAR 


Network  Design 

Allocation  of  Time  Slots  and  Protocols 
to  support  all  Mission  and  Comm’s 
IERs  within  a  Scenario 
Example:  NEA  2010  (Korea) 


Dynamic  Scenario 

Equipment  Deployments 
Mission  Deployments 
Movement  Paths 
Example:  NEA  2010  (Korea) 


Geography/T  errain 


Threat 

Warning  SAR 

Event  Call 

*  • 


Figure  10  -  Communications  Scenario  Architectural  Layers 


At  the  bottom  is  the  geography  of  the  area  of  interest  (AOI).  Next  is  the  force  deployment  and 
associated  dynamics  -  the  scenario  vignettes.  A  Network  Design  is  needed  for  the  force 
deployment  that  supports  the  communications  needs  of  the  operational  missions  including 
expected  traffic  levels,  required  response  times,  and  expected  events  and  surprise  events,  e.g., 
pop-up  targets.  A  communications  scenario,  or  mission  threads,  drives  traffic  over  the  networks 
as  the  scenario  vignettes  unfold,  and  in  response  to  dynamic  mission  events. 

After  several  GIESim  and  JSB-RD  team  discussions  on  whether  to  use  the  PACIFIA  or  Korean 
terrain,  the  team  ultimately  agreed  to  use  Korea  as  the  theater  of  interest.  This  allowed  for  great 
reuse  of  the  work  done  by  the  GIESim  team  for  the  SAB  Demo,  and  had  minimal  impact  of  the 
JSB-RD  team. 
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5.2  Physical  Architecture 


The  physical  architecture  of  the  GIESim-JSAF  merger  is  shown  in  Figure  11.  JSAF  and  the 
GIESim  JTIDS  simulation  from  PSI  are  the  two  main  components.  There  is  no  longer  an  RTI 
Server  since  RTI-S  is  nodeless. 

Entities  that  need  to  communicate  in  JSAF  via  JTIDS  need  to  have  counterparts  in  JTIDS.  These 
are  indicated  by  the  three  platforms  shown  in  each  simulation  in  Figure  11.  JSAF  and  JTIDS 
each  agreed  to  use  a  common  force  deployment  scenario  of  JTIDS  platforms. 


GIESim-JSAF  Merger  Physical  Architecture 


Figure  11  -  GIESim-JSAF  Physical  Architecture 


5.3  Logical  Architecture 

The  GIESim/JSB-RD  merger  team  agreed  to  use  the  GIESim  HLA  Interactions  that  were  defined 
for  the  GIESim  SAB  Demo  for  the  merger.  These  HLA  interactions,  with  minor  modifications, 
were  merged  with  the  Millennium  Challenge  02  (MC02)  FOM.  The  HLA  interactions  are 
discussed  further  in  Section  5.3.2. 

JSAF  has  flight  (movement)  paths  to  dynamically  move  aircraft,  and  sends  position  updates  to 
JTIDS  when  platforms  change  position.  A  flight  path  is  shown  as  a  solid  ellipse  within  JSAF  in 
Figure  1 1  and  as  a  dotted  ellipse  in  JTIDS.  The  enhancements  to  JTIDS  to  support  these 
operations  are  detailed  in  a  later  section  of  this  report. 

JTIDS  exercises  a  network  designed  to  support  the  tactical  communication  needs  of  the  entities 
in  JSAF,  and  sends  messages  between  selected  pairs  of  JTIDS  platforms.  This  is  shown 
notionally  in  right  side  of  Figure  1 1  as  green  radio  “links.”  JSAF,  on  the  other  hand,  was  given 
new  software  to  support  an  abstract  representation  of  JTIDS  communications  that  is  shown  in 
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Figure  1 1  as  dotted  lines.  Enhancements  to  the  JTIDS  simulation  to  support  external  network 
transmission  requests  will  be  detailed  in  a  later  section  of  this  report. 

PSI  worked  with  the  GIESim  and  JSAF  teams  to  ensure  that  entity  behaviors  were  operationally 
correct  relative  to  the  scenario  and  multi-simulation  environment  being  built.  Work 
accomplishments  in  this  area  included: 

•  PSI  worked  with  SAIC  to  investigate  platform  (entity)  behaviors  in  response  to 
communications  and  communications  outages  (lost  messages).  Figure  12  illustrates 
communications  message  strategies. 

5.3.1  Inter-simulation  Communications  Message  Handling 

A  major  challenge  in  defining  inter-simulation  communications  between  JSAF  and  JTIDS,  was 
that  JSAF  essentially  had  no  communications  models  or  concepts  built  into  it.  This  resulted  in 
the  need  to  define  entity  behaviors  that  had  to  must  deal  with  the  vagaries  of  tactical  radio 
communications. 

It  was  agreed  that  the  GIESim-JSAF  merger  would  follow  Strategy  B.  Messages  lost  in  JTIDS 
would  simply  not  be  reported  to  JSAF.  JSAF  would  introduce  a  message  “time  out”  that  would 
handle  lost  messages. 


Comm  Failure 
Strategy  "A" 


Comm  Failure 
Strategy  "B" 
(Most  Realistic) 


JSAF 


Send  &  Hold 


JTIDS 


Xmit 


HLA  Pub  MSG  SEND  , - , 
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\ 

ivioy  ri 

Send  &  Hold  HLA  Pub  MSG_SEND 

|  Msg  L| 
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C  -  Out  of  Range 
Segment  Dropped 
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Segment  Dropped 
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Figure  12  -  Inter-simulation  Messaging  Strategies 
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JSAF  holds  the  “actual”  message  to  be  transmitted,  and  provides  message  characteristic  to  JTIDS 
via  HLA.  Message  characteristics  include  message  size,  and  accumulated  latency.  When  JTIDS 
reports  that  a  particular  message  is  received,  then  JSAF  processes  it. 

Details  on  transmission  requests  and  message  receipt  between  JTIDS  and  JSAF  are  covered  in 
another  section  of  this  report. 

Changes  to  the  simulation  interface  and  the  internal,  logical  architecture  of  the  PSI  JTIDS 
simulation  were  designed,  developed  and  then  tested  to  support  the  physical  and  logical 
architecture  of  the  GIESim/JSB-RD  software  merger.  These  are  discussed  in  subsequent 
sections  of  this  Final  Report. 


5.3.2  GIESim  HLA  Interactions 

The  team  agreed  to  use  three  GIESim  HLA  Interactions  that  were  defined  for  the  GIESim  SAB 
Demo.  These  were: 

1 .  GIESIMMSGSEND:  For  sending  Link- 16  message  transmission  requests  from  JSAF 
to  JTIDS. 

2.  GIESIM  MSG  RCVD:  For  JTIDS  to  report  successful  reception  of  a  message  to  JSAF. 

3.  GIESIM  ENTITY  STATE:  For  JSAF  to  send  platform  position  updates  to  JTIDS. 

The  PSI  GSS  model  for  handling  these  HLA  interactions  is  shown  in  Figure  13. 


Figure  13  -  GSS  Model  to  Handle  GIESim  HLA  Interactions 


The  resources  in  the  top  layer  of  five  are  labeled  with  blue  text  to  indicate  that  they  are  HLA 
Resources.  This  means  that  GSS  automatically  “subscribes”  to  these  five  HLA  interactions. 
Lor  each  HLA  resource,  there  is  companion  resource,  e.g.,  SEND  MSG  DETAIL  below 
GIESIM  MSG  SEND.  The  HLA  resources  are  in  the  “public”  HLA  interface,  and  the 
companion  resources  are  used  to  expand  fields  in  the  public  HLA  resource. 
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Table  1  -  GIESIM  MSG  SEND  Interaction  Resources. 


***GIESIM  MSG  SEND************************************ 


ORIGINATING_ENTITY 
RECEIVING_ENTITY 
MESSAGE_ID 
MESSAGE_LENGTH 
CUMULAT I VE_LATENCY 
NET  TYPE  NUMBER 


CHAR  4 

CHAR  4 

INTEGER 

INTEGER 

REAL 

INTEGER 


***  TWO  INTEGERS 
***  TWO  INTEGERS 
***  UNSIGNED  LONG 
***  UNSIGNED  LONG 
***  FLOAT 

***  New  for  JSAF  **** 


*  *  *  SEND  MSG  DETAIL************************************ 


SEND_ORIG_ENTITY 

1  SEND_FED_ID  INDEX 

1  SEND_ENTITY_ID  INDEX 

SEND_RECV_ENTITY 

1  RECV_FED_ID  INDEX 

1  RECV  ENTITY  ID  INDEX 


SEND_MSG_ID 
SEND_MSG_LENGTH 
SEND_CUM_LATENCY 
SEND  NET  TYPE 


INTEGER 

INTEGER 

REAL 

INTEGER  ***  New  for  JSAF  **** 


Table  2  -  GIESIM  MSG  RCVD  HLA  Interaction  Resources 


*  *  *GIES IM_MSG_RCVD  ************************************* 

RECEIVING  ENTITY 
MESSAGE_ID 

CUMULAT I VE_LATENCY 

NET  ID 

CHAR  4  ***  TWO  INTEGERS 

INTEGER 

REAL 

INTEGER  ***  New  for  JSAF  **** 

*  *  *RECV_MSG_DETAIL*  *  *********************************** 

ENTITY  RECEIVED 

1  FED_ID 

1  ENTITY_ID 

INDEX 

INDEX 

RECV  MSG  ID 

RECV  SUM  LATENCY 

RECV  NET  ID 

INTEGER 

REAL 

INTEGER  ***  New  for  JSAF  **** 

Table  1  through  Table  3  list  the  contents  of  the  HLA  Resources  and  their  companions.  The 
companion  resources  show  the  detailed  breakout  of  all  HLA  interaction  parameters  and  their 
sizes.  New  parameters  that  were  added  to  the  GIESIMMSGSEND  and  GIESIM-MSG  RCVD 
HLA  interactions  are  noted  with  comments. 

This  specific  breakout  of  resources  was  sent  to  SAIC  to  help  resolve  interoperability  problems. 
The  new  field  in  the  GIESIM  MSG  SEND  interaction  was  named  NET  TYPE  NUMBER 
rather  than  simply  NET  TYPE,  so  the  team  agreed  to  change  the  FOM  to  match.  Also,  the 
NET  ID  field  was  added  to  the  GIESIM  MSG  RCVD  interaction  so  the  FOM  also  was  changed 
to  reflect  this  parameter. 

All  other  parameters  and  their  types  remained  the  same.  Explicit  sharing  of  these  tables  served 
too  clear-up  a  number  of  interoperability  problems. 
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Table  3  -  GIESIM  ENTITY  STATE  HLA  Interaction  Resources 


***GIESIM_ENTITY_STATE*********************************** 

ENTITY  TYPE 

CHAR  6 

ENTITY_IDENTIFIER 

INDEX 

HEADING 

REAL 

WORLD  LOCATION 

CHAR  12 

SPECIAL  EFFECT 

INTEGER 

*  *  *ENTITY_STATE_DETAIL*  *  ********************************* 

ENTITY  TYPE  DETAIL 

***  6  CHARS 

1  ENTITY_TYPE 

CHAR 

1  DOMAINX 

CHAR 

1  COUNTRY  CODE 

INDEX 

1  CATEGORY 

CHAR 

1  SUBCATEGORY 

CHAR 

ENT I T Y_I D_DETAI L 

INDEX 

HEADING  DETAIL 

REAL 

WORLD_LOCATION_DATA 

1  LAT 

REAL 

1  LON 

REAL 

1  ALT 

REAL 

SPECIAL  EFFECTS  DATA 

INTEGER 

Additional  discussion  on  design,  development  and  testing  of  these  HLA  interactions  and 
associated  processing  is  presented  in  subsequent  sections  of  this  report. 
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5.4  Scenario  Development 


Once  the  combined  GIESim  JSB-RD  team  agreed  to  use  Korea  as  the  theater  of  interest,  a 
Korean-based  scenario  was  needed.  PSI  volunteered  use  of  its  Korona  scenario  that  was 
developed  to  support  testing  of  our  Link- 16  Network  Management  System  (NMS)  under  contract 
with  another  AFRL  Group.  A  complete  description  and  a  full  set  of  deployment  data  for  Korona 
and  Korona- WDL  (a  Weapons  Data  Link  variant)  were  sent  to  the  team  in  July  04. 

5.4.1  PSI  Korona  Scenario 

The  composition  of  Korona  is  based  upon  the  Blue  force  disposition  of  the  NEA  III  2010  ATO 
Excursion  described  in  the  “TECHNICAL  REPORT  2003,  Single  Integrated  Air  Picture  (SIAP), 
Link  16  Networking/Throughput,  Network  Design  Analysis,  November  2003,  Joint  SIAP 
System  Engineering  Organization  (JSSEO)”.  Rather  than  use  the  classified  platform 
deployments  of  the  SIAP  reference  scenario,  PSI  created  an  unclassified  deployment  called 
Korona.  Figures  1  and  2  show  full  views  of  Korona  platforms  and  movement  profiles. 

The  force  composition  of  the  Korona  scenario  is  listed  in  Table  4.  The  Korona  scenario  includes 
87  profiles.  A  large  part  of  building  Korona  was  the  creation  of  operationally  meaningful 
profiles,  i.e.,  movement  paths.  A  high  percentage  of  the  platforms  are  assigned  to  individual 
profiles. 

Korona  has  3  Areas  of  Operation  (AO)  as  shown  in  Figure  16.  In  each  AO,  there  is  a  target 
“protected”  by  four  ground  threats,  e.g.,  SAM  sites.  Icons  indicate  the  targets  and  ground  threats 
and  provided  a  focus  for  developing  mission  profiles. 

Each  AO  has  several  missions.  Suppression  of  Enemy  Air  Defense  (SEAD)  missions  were 
supported  by  FI 5s  that  go  in  first  to  take  out  air  defenses  and  then  STRIKER  missions  were 
assigned  to  FI 8s  to  go  in  to  hit  ground  targets.  One  SEAD  aircraft  was  assigned  to  each  air 
defense  target  and  four  Strikers  were  assigned  to  each  main  target.  Combat  Air  Patrol  (CAP) 
and  Escort/Reserve  aircraft  supported  the  SEAD  and  Striker  missions.  Aircraft  assigned  to  the 
AO’s  followed  Ingress  and  Egress  routes  as  illustrated  in  Figure  16. 

Ultimately,  a  subset  of  the  PSI  Korona  scenario  was  chosen  as  one  part  of  the  scenario  for  the 
merger. 
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Figure  14  -  Full  View  of  PSI  Korona  Scenario  over  Korean  Terrain 
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Figure  15  -  Full  View  of  PSI  Korona  Scenario  over  Political  Boundaries 
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Table  4  -  Force  Composition  of  the  PSI  Korona  Scenario 


AB  IFC  Sensor 

2 

ABL 

4 

KC  135 

5 

Air  Cav  Helo 

2 

w 

E 

E2C 

6 

a 

E3 

1 

CB 

F15F 

24 

Q_ 

F18 

24 

< 

JLENS 

3 

JSTARS 

2 

Rivet  Joint 

2 

Global  Hawk  UAV 

12 

Total  Air 

87 

CAC2S 

6 

CRC 

2 

JTAGS 

4 

■g  Patriot  ICC 

4 

g  SHORAD 

2 

5  TOAM 

2 

THAAD  TOC 

4 

UAV  Grnd  Station 

1 

Total  Ground 

25 

Carriers 

2 

CO 

0 

Cruisers 

15 

CO 

Submarine 

1 

Total  Sea 

18 

Total  Moving 


105 


Total  Stationary_ 25 


Total  Link-16  Platforms  130 


[Movement  Paths 


Reference  Icons 

18 

Navy  Carrier  Groups 

2 

Figure  16  -  Areas  of  Operation  (AOs)  in  basic  Korona  Scenario. 
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Scenario  planning  involved  an  analysis  of  the  platforms  available  and  their  missions.  For 
example,  a  KC-135  tanker  might  support  both  in-air  refueling  and  also  serve  as  a  relay  platform. 
Scenario  planning  also  involved  assignments  of  speeds,  which  can  (and  may  likely),  vary 
throughout  the  scenario,  altitudes,  and  timing.  Altitudes  along  movement  profiles  were 
“deconflicted”  and  reflect  platform  capabilities  in  addition  to  their  missions.  Expert  input  on 
missions  and  tactical  considerations  was  used  to  build  realistic  scenarios. 

The  “basic”  Korona  scenario  has  an  altitude  plan  that  is  shown  in  Figure  17,  which  reflects 
research  and  expert  inputs  on  altitudes  typically  associated  with  the  platform  types  in  the 
scenario.  Figure  18  shows  typical  speeds  for  these  platforms.  The  altitude  and  speed  values 
differ  for  the  SEAD,  STRIKER,  and  Escort/CAP  aircraft. 


Figure  17  -  Altitude  Plan  for  Korona. 

The  Korona  scenario  assumes  that  the  campaign  is  many  days  or  weeks  old,  and  several  hours 
into  the  current  scenario.  This  implies  that  all  support  missions,  e.g.,  tankers,  surveillance,  etc. 
are  “on  station”  and  therefore  traveling  stationary  orbits.  The  scenario  starts  with  the  fast-mover 
SEAD,  Striker  and  their  CAP  support  already  past  launch  time  and  well  into  ingress  and  pushing 
towards  their  targets. 
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Figure  18  -  Platform  Speeds  in  Korona. 


When  deploying  the  land,  air  and  sea  platforms,  the  scenario  takes  into  account  how  each  should 
be  deployed  based  on  the  current  “time”  of  the  scenario  and  their  characteristics.  For  instance, 
FI 5s  can  serve  both  CAP  and  Strike  missions,  and  FI 8s  can  serve  CAP  and  SEAD  missions. 
E2Cs  handle  surveillance  and  relaying  in  the  vicinity  of  naval  task  groups.  E3s  handle 
surveillance  at  a  standoff  distance  from  the  action.  KC-135  tankers  need  to  be  located  near 
ingress  and  egress  routes  for  refueling  and  can  also  act  as  relays.  Global  Hawk  UAVs  fly  up  at 
60,000  feet  to  transmit  video  and  other  surveillance  information.  Movement  profiles  reflect  the 
platform  assignments  in  terms  of  speeds,  altitudes,  locations  and  timing. 

Tactical  Aircraft  Deployment 

The  Korona  scenario  includes  24  FI 5s  and  24  FI 8s.  These  aircraft  had  to  be  allocated  to 
different  missions  across  the  scenario.  Table  5  shows  how  these  aircraft  were  deployed.  Figure 
19  shows  the  SEAD  profiles  with  respect  to  the  3  Areas  of  Operation  (AO)  and  Figure  20  shows 
the  Striker  missions  over  the  main  target  in  each  AO. 
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Table  5  -  Deployment  of  FI  5  and  FI  8  Fighter  Aircraft. 


CAP  Locations 

AOI  (West) 

A02  (Central) 

A02  (East) 

CEN 

CAP 

CW 

CAP 

SW 

CAP 

NE 

CAP 

SW_N 

CAP 

SEAD 

STRIKER 

CAP 

R/E 

SEAD 

STRIKER 

CAP 

R/E 

SEAD 

STRIKER 

CAP 

R/E 

Total 

F15 

2 

2 

2 

4 

2 

4 

2 

4 

2 

24 

F18 

2 

2 

2 

4 

2 

4 

2 

4 

2 

24 

Total 

12 

12 

12 

12 

48 

CAP 

Combat  Air  Patrol 

STRIKER 

Strike  Aircraft  associated  with  a  Target 

SEAD 

Suppression  of  Enemy  Air  Defenses 

R/E 

Reserve/Escort 

In  the  basic  Korona  scenario,  the  SEAD  and  Striker  mission  profiles  were  directed  over  their 
associated  targets.  Flight  paths  were  designed  for  SEAD  missions  to  ensure  that  ground  threats 
were  attacked  in  close  synchronization.  Similarly,  the  flight  paths  for  the  STRIKER  missions 
were  designed  for  close  synchronization  of  attacks  that  took  place  from  different  directions. 
Flight  path  waypoint  positions,  altitudes  and  segment  speeds  were  adjusted  to  reflect  the  mission 
profile  and  capabilities  of  each  aircraft. 


Figure  19  -  Korona  F18  SEAD  Mission  Profiles. 
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Figure  20  -  Korona  F15  STRIKER  Missions. 


Since  the  team  wanted  to  have  a  simple  scenario  to  demonstrate,  and  one  that  had  visual  (and 
emotional)  impact,  PSI  proposed  and  finally  built  a  simple  though  operationally  relevant  and 
timely  scenario,  that  came  to  be  called  the  “Wow”  scenario.  This  scenario  was  selected  by  the 
team,  and  is  described  in  the  next  section  of  this  report. 
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5.4.2  “Wow”  Scenario 


The  GIESim/JSB-RD  team  was  looking  for  a  demonstration  scenario  that  was  simple,  had  a 
short  run  time,  was  operationally  viable,  and  that  had  emotional  and  visual  impact  and  that 
demonstrated  the  value  of  GIESim  communications  modeling  to  JSAF.  PSI  proposed  the 
scenario  shown  in  Table  6  in  late  August  that  eventually  became  known  as  the  “Wow”  scenario. 


Table  6  -  Initial  "Wow”  Scenario  Description  from  PSI 


Scenario  Set-up: 

A  tactical  STRIKER  aircraft  is  following  terrain  during  ingress  to  a  strategic  target.  Some  ways  ahead,  a 
SOF  guy  on  the  ground  in  range  of  the  target  suddenly  detects  a  mobile  SAM  site.  The  SOF  guy  is 
separated  from  the  STRIKER  by  a  mountain  ridge. 

JSAF  w/o  Comms: 

The  SOF  guy  “notifies”  the  STRIKER  who  evades  the  SAM.  Everybody  is  happy,  but  the  simulation  is 
unrealistic,  and  worse,  it  erroneously  predicts  the  good  guy  gets  away. 

JSAF  w/  Comms  but  no  relay: 

The  SOF  guy  uses  JTIDS  to  send  a  threat  warning  to  the  STRIKER  but  the  mountain  range  blocks  direct 
radio  contact.  The  STRIKER  gets  hit.  Explosion.  Good  guy  buys  it.  Lesson:  We  need  to  account  for 
distance  and  terrain  in  realistic  mission  planning. 

Add  Relay:  Based  on  the  results  of  the  prior  run,  we  turn  on  a  JTIDS  relay  -  maybe  a  UAV.  Now  the 
STRIKER  gets  the  relayed  threat  warning  and  evades! ! 

Lesson:  Communications  modeling  and  advanced  communications  planning  in  support  of  operations  is 
critically  important.  JSAF  needs  GIESim  for  communications  modeling. 


After  some  discussion,  the  team  embraced  the  “Wow”  scenario,  and  PSI  was  asked  to  build  it. 
PSI  sent  its  first  version  of  the  “wow”  scenario  to  the  team  on  October  1 1 .  The  scenario  was 
shown  in  a  series  of  screen  shots  plus  data  for  the  flight  paths  and  ground  positions. 

Building  the  “wow”  scenario  required  some  searching  for  an  appropriate  area.  A  long  valley  was 
needed,  and  the  SOF  had  to  be  positioned  carefully  to  attain  the  desired  terrain  masking  for  the 
scenario.  The  new  2D  terrain  and  contours  available  with  the  PSI  Link- 16  Planning  Tool  made 
the  job  tractable  and  easy  to  accomplish. 

Screen  shots  of  the  “Wow”  scenario  follow  along  with  brief  explanations. 
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Figure  21  -  Wow  Scenario  (yellow  rectangle)  addition  to  Korona 


Figure  21  shows  the  wow  scenario  that  was  added  to  the  Korona.  The  figure  shows  the  new  2D 
terrain  and  contours  that  are  available  in  GSS  as  of  Release  10.3.6. 
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Figure  22  -  Close-up  of  "Wow"  Scenario 

Figure  22  shows  a  close-up  of  the  “wow”  scenario  that  shows  the  FI  5  STRIKER,  Global  Hawk 
UAV  relay,  SOF,  target  (red  square),  and  pop-up  threat  (gold  cross).  Green  lines  indicate  good 
Link- 16  radio  connectivity.  Note  that  the  F15  has  good  connectivity  with  the  SOF  at  the  start  of 
its  attack  run,  while  it  is  still  at  a  high  altitude. 
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Figure  23  -  Lost  connectivity  between  the  F15  and  SOF  due  to  terrain 

As  the  F15  drops  altitude  to  start  following  the  terrain,  RF  connectivity  between  the  FI 5  and  the 
SOF  is  lost  due  to  the  mountainous  terrain.  This  is  shown  in  Figure  23.  Note  that  there  is  still 
good  connectivity  between  the  F15  and  UAV,  and  between  the  UAV  and  the  SOF.  This  makes 
the  UAV  an  excellent  candidate  for  being  a  relay. 

Once  the  F15  has  completed  its  attack  run,  and  begins  to  climb,  connectivity  with  the  SOF 
begins  to  reestablish  as  shown  in  Figure  23.  The  dotted  yellow  line  indicates  unidirectional 
connectivity.  In  this  case  since  the  F15  is  transmitting  at  100  watts  and  the  SOF  at  25  watts,  the 
SOF  can  hear  the  F15  transmissions.  When  the  F15  gains  more  altitude  then  full  connectivity  is 
restored  as  shown  in  Figure  25. 
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Figure  24  -  F15-SOF  connectivity  starts  to  reestablish 

Ultimately  the  team  selected  the  PSI  “Wow”  scenario  for  it  simplicity,  and  for  its  operational 
relevance  and  timeliness.  The  data  for  the  “Wow”  Scenario  is  provided  in  this  report  as 
Appendix  A. 

The  next  section  of  this  report  describes  the  specific  JTIDS  networks  that  were  defined  by  PSI  to 
support  the  “Wow”  scenario.  Whereas  the  original  plans  called  for  two  scenarios,  one  scenario 
with  and  another  scenario  without  the  UAV  relay,  we  ultimately  built  a  single  scenario  (and 
single  associated  network  design)  that  included  the  UAV.  JSAF  can  simply  move  the  UAV  out 
of  position  whenever  we  chose  to  demonstrate  lack  of  RF  Link  connectivity  and  the  associated 
importance  of  the  UAV  relay. 
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Figure  25  -  SOF-F15  connectivity  restored  at  end  of  mission 
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5.5  JTIDS  Network  Definition  and  Design 


The  “ definition  ”  of  a  JTIDS  network  refers  to  capturing  or  defining  the  requirements  of  the 
network,  also  referred  to  as  the  Information  Exchange  Requirements  (IERs).  The  “ design  ”  of  a 
JTIDS  network  refers  to  the  process  of  allocating  appropriate  time  slots  and  assigning  them  to 
JTIDS  platforms  based  on  the  needs  of  the  network  definition.  A  network  definition  includes 
what  platforms  have  to  communicate,  which  TADIL-J  messages  to  use,  response  time  needs, 
type  of  network  access  required,  etc. 

For  the  “Wow”  scenario,  the  three  networks  shown  in 

Table  7  were  defined.  The  Threat  Warning  operational  net  was  given  a  very  fast  response  time 
of  1  second,  uses  a  J15.0  message,  and  is  intended  for  the  SOF  to  warn  the  F15(s).  The  Mission 
Control  Operational  Net  is  intended  for  the  SOF  to  send  the  FI 5  a  message  to  engage  the  pop-up 
target.  The  Engagement  Status  net  is  intended  for  the  F15  to  send  mission  status  messages  to  the 
SOF. 


Table  7  -  "Wow"  Scenario  Network  Requirements 


Network  File  Name:  Korona-WOW-F15.NET 


NET_TYPE  Access  TDL_J  Response 

Net  Label  #  Mode  Message  Source  Destinations  Time  (Sec) 


THREAT  WARNING 

14 

Dedicated 

J15.0 

SOF  1 

FI 54  WA04.Lead 

FI 5  WA04.2 

FI 5  WA04.2 

FI 5  WA04.4 

1 

MISSION  CONTROL 

15 

Dedicated 

J12.7 

SOF  1 

FI 5  WA04.Lead 

FI 5  WA04.2 

FI 5  WA04.2 

FI 5  WA04.4 

2 

Receiver 

Contention  Sources  /  Transmitters 

ENGAGEMENT  STATUS 

16 

Contention 

J12.6 

S0F1 

F15 WA04.Lead  |  F15 WA04.2  |  F15 WA04.2  |  F15 WA04.4 

2 

The  Planning  Tool  from  the  PSI  Link- 16  NMS  was  used  to  capture  the  network  requirements 
definition.  Before  the  Planning  Tool  could  be  used  however,  new  “generic”  nets  had  to  be 
defined  in  support  of  the  tactical  elements  in  the  “Wow”  scenario.  The  Generic  Operational  Net 
Database  Manager  was  used  to  define  these  new  generic  net  types,  e.g.,  SOF  to  F15  Threat 
Warning  net.  Then  the  PSI  Link- 16  Planning  Tool  was  used  to  capture  and  refine  the  network 
requirements.  The  “Wow”  network  requirements  were  added  to  the  networks  previously  defined 
for  the  Korona  Scenario. 

The  Planning  Tool  was  used  to  automatically  launch  the  Automated  Resource  Allocation  and 
Assignment  Tool  (TSA),  which  allocated  the  required  time  slots  in  a  matter  of  minutes.  Note 
that  this  process  is  typically  manual,  and  can  take  hours  or  days  to  accomplish.  The  PSI  Link- 16 
NMS  has  automated  the  entire  Link- 16  management  process  including  time  slot  allocation,  and 
is  therefore  both  easy  and  fast  to  use. 

The  resulting  network  file,  Korona-WOW-F15.NET,  contains  both  the  network  requirements 
and  time  slot  allocations  and  assignments  for  the  Korona-Wow  scenario. 

Note  that  the  PSI  Link- 16  Planning  Tool  was  modified  to  produce  an  ENTITY  map  file, 
ENTITY.OUT,  and  a  file,  NETMAPFILE.TXT,  which  contains  a  list  of  the  NETTYPE  numbers 
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in  the  network.  Table  8  shows  the  NET  TYPE  numbers  for  the  combined  Korona-Wow  scenario 
and  networks. 


Table  8  -  "Wow"  Network  NET  TYPE  Numbers 


NETTYPE 

# 

Network  Description  Label 

Designed  for... 

1 

RTTB 

2 

AIRCONTROL  UPLINK 

3 

ELECTRONIC  WARFARE 

4 

FTRT  OFTRT  ARG  ET 

5 

ENGAGEMENT  COORD 

Korona 

6 

RESIDUAL  MSG 

7 

NEEDLINE 

Network 

8 

PPLI  A 

Types 

9 

V0ICE 1 

10 

VIDEODOWNLINK 

11 

PPLI  B 

12 

MISSION MGT 

13 

SURVEILLANCE 

Purpose  of  Wow  Net  Type  (See  Wow  Network  tab  for  details) 

14 

THREAT  WARNING 

Wow 

Used  to  send  Threat  Warning  from  SOF  to  any  FI  5  in  the  net 

15 

MISSION  CONTROL 

Scenario 

Used  to  send  Mission  Assignment/Target  information  from  SOF  to  FI 5s  in  the  net 

16 

ENGAGEMENT  STATUS 

Network 

Any  FI 5  can  send  engagement  status  to  the  SOF 

Figure  26  shows  a  screen  shot  of  the  Operational  Net  List  from  the  JTIDS  Simulation  that  has 
loaded  the  new  Korona-WOW-F15.NET  file.  The  three  highlighted  networks  show  the  new 
operational  nets  that  were  designed  for  the  “Wow”  scenario. 


H  Operational  Net  List 


^jnjxj 


NET 

NET  TYPE 

SOURCE  TYPE 

SOURCE  ID 

MISSION 

M 

JN 

ACT 

# 

G 

A 

ID 

0 

E 

TYPE 

A 

R 

CC 

D 

T 

c 

P 

E 

L 

T 

ID 

SS 

89 

MISSION_MGT 

THAAD_TOC 

THAADTOC_2_2 

2 

DMEA 

0 

D  A 

90 

MISSION_MGT 

THAAD_TOC 

THAADTOC_2_3 

2 

DMEA 

0 

D  111 

91 

MISSION_MGT 

THAAD_TOC 

THAADTOC_2_4 

2 

DMEA 

0 

D 

92 

SURVEILLANCE 

INCREMENTAL 

6 

DMEA 

0 

1 

93 

SURVEILLANCE 

INCREMENTAL 

6 

DMEA 

0 

1  111 

94 

SURVEILLANCE 

INCREMENTAL 

6 

DMEA 

0 

1  H 

95 

PPLI_B 

KC  _1 35 

ABRLYJ  j 

19 

DMEA 

0 

D 

96 

PPLI_B 

KC_1 35 

ABRLY_3_1 

19 

DMEA 

0 

D 

97 

THREAT  WARNING 

TACP 

S0F_1 

1 

DMEA 

0 

D  H 

98 

MISSION  CONTROL 

TACP 

S0F_1 

1 

DMEA 

0 

™||| 

99 

ENGAGEMENT  STATUS 

CONTENTION 

1 

DMEA 

0 

- . 


Show  Net  Control 

Show  Platform  Control 

Show  Net  Destinations 

Close 

Figure  26  -  Operational  Net  List  Showing  New  Nets  for  the  "Wow"  Scenario 


It  is  worth  noting  that  there  was  considerable  team  misunderstanding  over  how  JTIDS  relays 
work.  At  first  the  team  thought  that  explicit  message  transmission  requests  had  to  be  sent  to  and 
from  JTIDS  relays,  a  thought  that  greatly  complicated  code  development  in  JSAF.  In  reality,  any 
JTIDS  radio  can  be  configured  to  act  as  a  transparent  relay  as  in  the  case  with  the  UAV  in  the 
“Wow”  Scenario.  Therefore,  all  JSAF  had  to  do  was  to  send  position  updates  to  JTIDS,  and  the 
JTIDS  simulation  would  automatically  handle  message  relaying  through  the  UAV  due  to  the 
design  of  the  network.  This  clarification  greatly  simplified  efforts  within  JSAF. 
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5.6  GIESim/JSB-RD  Merger  M&S  Design 


This  section  primarily  covers  the  technical  design  changes  associated  with  the  PSI  JTIDS 
simulation  for  the  GIESim-JSAF  merger. 


5.6.1  RTI-S  Design  &  MC02plus  FOM 

Since  JSAF  uses  RTI-S  rather  than  the  DMSO  RTI,  PSI  needed  to  move  to  its  use.  There  was 
also  a  desire  to  move  the  GIESim  SAB  Demo  to  RTI-S,  so  that  we  only  had  to  deal  with  a  single 
RTI  rather  than  two.  This  was  ultimately  accomplished. 

A  copy  of  the  RTI-S  was  obtained  in  a  release  of  JSAF  that  was  provided  by  the  AFRL  JSB-RD 
group.  Design  changes  required  the  replacement  of  the  DMSO  RTI  with  the  nodeless  RTI-S. 
This  ultimately  required  minor  changes  to  the  PSI  GSS  development  environment. 

Use  of  RTI-S  required  use  of  a  new  rid  file  (RTI-s_l.3D9A.rid),  which  is  supplied  with  the  RTI- 
S  distribution.  In  addition,  since  PSI  is  currently  using  MS  VC++  6.0,  we  needed  to  use  the 
winnt_vc++6-0  version  of  the  RTI-S  library  from  the  RTI-S  distribution. 

JSAF  currently  uses  the  Millennium  Challenge  02  FOM,  therefore  a  requirement  of  the  merger 
was  to  use  content  of  this  FOM  “merged”  with  the  FOM  that  was  developed  by  GIESim  team. 

Details  on  the  development  and  testing  with  the  merged  MC02++  FOM  are  covered  in  Sections 

5.7.1  and  5.8.1  respectively. 
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5.6.2  GIESim-JSAF  JTIDS  Design 


The  requirements  analysis  for  the  GIESim-JSAF  merger  led  to  the  following  requirements  for 
the  version  of  the  PSI  JTIDS  simulation  for  the  merger: 

•  Entity  Mapping  for  Link- 16  platform  references  exchanged  between  JSAF  and  JTIDS 

•  Creation  of  Entity  map  for  use  by  JSAF  based  on  a  common  force  scenario. 

•  Update  of  Link- 16  platforms  based  on  position  updates  received  from  JSAF  via 
GIESIM  ENTITY  STATE  HLA  interactions. 

•  Creation  of  a  NetTypes  file  for  use  by  JSAF  based  on  the  network  that  is  designed  to 
meet  their  requirements. 

•  Need  to  modify  the  GIESIMMSGSEND  HLA  interaction  with  the  addition  of  a 
NETTYPE  field. 

•  Need  to  receive  and  act  on  Link- 16  message  transmission  requests  sent  by  JSAF  in  the 
form  of  modified  GIESIM  MSG  SEND  HLA  interactions. 

•  Notify  JSAF  by  sending  a  GIESIMMSGRCVD  HLA  interaction  when  a  Link- 16 
message  is  received  by  the  target  destination 

Since  the  PSI  Link- 16  Planning  Tool  would  be  used  to  design  the  common  scenario  and 
associated  network  requirements  and  design,  its  design  was  modified  to  output  an  Entity  Map 
and  an  enumerated  list  of  NetTypes.  Both  JSAF  and  the  modified  PSI  JTIDS  simulation  use 
these  output  files.  Figure  27  shows  the  modified  PSI  Planning  Tool  and  output  files. 


GIESim-JSAF 

Requirements 

Inputs 


To  JSAF  & 
Link-16  Sim 


To  JSAF 


To  Link-16 
Simulation 


Figure  27  -  Modified  Link-16  Planning  Tool  for  GIESim-JSAF  Merger 


Figure  28  shows  the  high-level  design  of  JSAF  and  JTIDS  with  associated  files  and  HLA 
interactions.  Both  JSAF  and  JTIDS  need  to  use  the  same  MC02plus  FOM.  JTIDS  directly  uses 
the  Network  Requirements  and  Designs  output  by  the  PSI  Link- 16  Planning  Tool  and  automated 
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Time  Slot  Allocation  and  Assignment  Tool.  JSAF  inputs  and  uses  the  contents  of  the  NetType 
file  for  making  Link-16  network  transmission  requests  to  JTIDS.  Both  JTIDS  and  JSAF  input 
force  composition  elements  from  the  common  force  scenario.  Each  simulation  uses  its  own 
internal  representation  of  Link- 16  platform  reference  -  hence  the  need  for  Entity  mapping  that  is 
described  in  the  next  section.  The  movement  paths  from  the  common  scenario  are  mapped  into 
the  internal  representation  in  JSAF.  Since  JSAF  drives  position  updates  into  JTIDS,  JTIDS  does 
not  require  movement  paths. 


Figure  28  -  High-level  Design  of  JSAF-JTIDS  Merger 


The  remainder  of  this  section  will  address  each  specific  design  requirement  in  turn. 


5.6.2.1  Entity  Mapping  Design 

As  discussed  earlier  and  as  shown  in  Figure  28,  HLA  interactions  are  used  to  send  position 
updates  and  to  make  transmission  requests  and  to  report  reception  of  messages  from  a  particular 
platform;  GIESIM  ENTITY  STATE,  GIESIM  MSG  SEND  and  GIESIM  MSG  RCVD  HLA 
interactions  are  used  for  these  respectively.  Internal  to  each  HLA  interaction  are  one  or  more 
ENTITY_IDs.  The  simulations  use  these  IDs  to  make  specific  platform  references  with  respect 
to  a  common  scenario. 
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For  human  readability,  platforms  are  usually  given  specific  names  in  the  scenario,  e.g.,  FI 51.1, 
and  E3(l).  Each  simulation  then  maps  these  names  to  its  own  internal  representation,  usually 
numeric  values  or  keys.  Therefore,  a  mechanism  was  needed  for  simulations  to  exchange 
platform  IDs  in  a  way  that  simplified  the  interface  fast  exchange  of  HLA  messages. 

The  GIESim/JSB-RD  team  agreed  to  use  an  Entity  mapping  provided  by  PSI.  Our  Entity 
mapping  approach  takes  each  platform  label,  i.e.,  string,  in  the  common  scenario  file  and  runs  it 
through  a  hashing  function  to  produce  a  unique  numeric  value  for  each  platform  label.  Each 
simulation  then  maps  this  hashed  value  to  its  own  numeric  representation  for  the  platform. 

As  shown  in  Figure  27,  the  PSI  Link- 16  Planning  Tool  provides  the  Entity  Map  from  the 
common  scenario  file. 


5.6.2.2  Design  of  HLA  Platform  Position  Updates 

JSAF  sends  platform  position  updates  from  JTIDS.  Figure  29  illustrates  the  operations.  JSAF 
and  JTIDS  each  load  the  same  scenario  of  JTIDS  platforms.  In  JSAF  mobile  platforms  will 
navigate  on  flight  paths.  Many  of  these  paths  are  similar  or  exactly  the  same  as  those  PSI 
created  in  its  Korona  and  “Wow”  scenario.  In  JTIDS,  mobile  platforms  follow  “virtual”  flight 
paths  based  on  periodic  position  updates  received  from  JSAF.  GIESIM  ENTITY  STATE  HLA 
interactions  are  sent  from  JSAF  to  JTIDS  to  update  positions. 


JSAF  Enhanced  JTIDS 


XT  Old 

New  _  ... 

r,  .. .  Position 

Position 

GIESim 

ENTITY_STATE 

Message 

Updated  Current 

Position  Position 

Flight  Path 

*  « 

Virtual  Flight  Path 

JTIDS  Driver 
“JSAF  Surrogate” 


Map  Entity  ID  Numbers 

Figure  29  -  JSAF  Platform  Position  Updates  into  JTIDS 


Therefore,  a  version  of  the  PSI  JTIDS  simulation  was  created  for  the  GIESim-JSAF  merger  to 
accept  external  position  updates.  In  order  to  support  early  interoperability  tests  internal  to  PSI, 
enhancements  were  also  designed  into  JTIDS  to  allow  it  to  generate  HLA  position  updates.  This 
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allowed  us  to  test  the  interface  using  complex  scenarios  with  different  update  rates  typical  of 
what  was  expected  to  come  from  JSAF. 


5. 6. 2. 3  JSAF-JTIDS  Network  Transmission  Design 

When  the  internal  logic  in  JSAF  determines  that  one  platform  needs  to  send  a  message  to  another 
platform  via  Link- 16,  it  will: 

a)  Build  the  message  with  a  unique  ID  number  and  determine  its  size 

b)  Obtain  the  mapped  IDs  of  the  sending  and  receiving  platforms 

c)  Determine  the  type  of  Network  to  send  the  message  on 

d)  Build  a  GIESIMMSGSEND  message  that  encodes  the  above  information,  and  then 

e)  Sends  it  over  HLA  to  the  JTIDS  Simulation. 

The  JSAF  simulation  will  hold  the  message  until  one  of  two  things  happens: 

a)  It  receives  a  GIESIM  MSG  RCVD  interaction  from  JTIDS  for  the  receiving  platform,  or 

b)  A  message  receive  time-out  occurs. 

SAIC  is  adding  the  appropriate  logic  to  JSAF  to  support  these  operations. 


Comm  Enhanced  Enhanced 

JSAF  JTIDS  Simulation 


Figure  30  -  JTIDS  Sim  Adding  Communications  to  JSAF 


Figure  30  and  Figure  3 1  illustrate  the  simulation  interfacing  between  JSAF  and  JTIDS,  and  the 
resulting  Link- 16  message  transmission  handling. 
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JSAF  Time-out 
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JSAF  Msg  ID 

JSAF Msg ID 

—  ^ 

I  Message  Lost 
I  -  Out  of  Range 
Segment  Dropped 
9  -  Etc. 


No  Message 


Figure  31  -  Functional  Messaging  Relationship  of  JSAF  and  JTIDS 


On  the  side  of  the  JTIDS  simulation,  enhancements  to  JTIDS  support  several  operations  that  take 
place  when  a  GIESIMMSGSEND  interaction  is  received: 

a)  JTIDS  performs  validity  checks  on  the  HLA  message  content  received. 

b)  JTIDS  uses  the  Source  and  Destination  IDs  to  look-up  these  platforms  in  its  internal 
database. 

c)  JTIDS  uses  the  Net  Type  field  (see  next  section)  to  set  parameters  that  will  be  used  to 
find  an  Operational  Net  to  support  the  message  transmission. 

d)  If  JTIDS  can  find  an  Operational  Net  of  the  correct  type  and  with  the  required  source  and 
destination  platform,  then  it  starts  transmission  of  the  message  through  the  chosen  JTIDS 
network,  otherwise  the  request  is  dropped  silently,  e.g.,  no  HLA  message  is  sent  to  JSAF. 

Note  that  JTIDS  will  perform  message  segmentation  and  reassembly  (SAR)  on  messages  that 
exceed  the  capacity  of  the  operational  net.  More  details  on  these  operations  are  described 
shortly. 

When  all  segments  of  a  particular  ID  message  are  received  within  JTIDS,  then  JTIDS  will: 

a)  Determine  the  additional  latency  that  was  added  by  the  total  transmission  process, 
including  SAR. 

b)  Build  a  GIESIM  MSG  RCVD  interaction  with  the  destination  platform  ID,  JSAF 
message  ID  and  latency. 

c)  Send  the  HLA  interaction  out  over  the  HLA  for  the  JSAF  simulation  to  receive. 

The  JTIDS  simulation  interface  was  enhanced  to  support  these  operations. 
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5. 6. 2.4  Net  Types  &  Network  Design 


Link- 16  Operational  Nets  and  their  associated  time  slot  allocations  and  assignments  are  required 
to  support  the  communications  requirements  of  the  scenario  running  in  JSAF. 

PSI  had  previously  designed  several  networks  to  support  and  test  our  Korona  scenarios.  These 
Korona-oriented  networks  served  as  the  basis  for  the  JSAF-JTIDS  network  that  was  described 
earlier  in  Section  5.5.  Whereas  network  transmissions  occur  automatically  in  PSI’s  standard 
JTIDS  simulation,  enhancements  were  needed  to  allow  transmissions  between  platforms  to  occur 
as  a  result  of  external  HLA  requests. 

For  this  purpose  the  following  design  changes  were  introduced: 

1 .  A  NETTYPE  field  was  added  to  the  GIESIMMSGSEND  interaction.  This  allows 
JSAF  to  specify  by  type  number,  the  nature  of  the  communication.  See  Figure  32. 

2.  The  PSI  Link- 16  Planning  Tool  was  modified  to  create  NetType  maps  from  the  network 
designed  to  support  the  common  JSAF-JTIDS  scenario.  See  Figure  27. 

3.  A  NetType  Map  in  JTIDS  that  maps  the  NET  TYPE  number  to  a  particular  network  type 
definition,  e.g.  “AIRCONTROLUPLINK”. 


***SEND  MSG  DETAIL 


SEND  ORIG  ENTITY 


1  SEND_FED_ID 

INDEX 

1  S  END_ENT I T Y_ I D 

INDEX 

SEND  RECV  ENTITY 

1  RECV_FED_ID 

INDEX 

1  RE  C V_ENT I T Y_ I D 

INDEX 

SEND_MSG_ID 

INTEGER 

SEND_MSG_LENGTH 

INTEGER 

S END_C UM_L  ATENC  Y 

REAL 

S  END_NE  T_T YP  E 

INTEGER 

Figure  32  -  Added  NET_TYPE  Field 


Table  8  lists  the  NetTypes  that  were  defined  for  the  PSI  created  Korona- WDL  scenario,  along 
with  the  actual  NET  TYPE  enumerations.  Based  on  the  type  of  message  that  a  JSAF  platform 
“wishes  to  send”,  e.g.,  Engagement  Status  -  NET_TYPE  16,  JSAF  will  choose  the  appropriate 
NET  TYPE.  JSAF  and  JTIDS  need  to  use  this  common  net  mapping  produced  by  PSI. 

Internal  to  JTIDS  there  is  a  database  of  operational  nets,  and  each  net  has  a  field  that  lists  its 
operational  type.  Therefore,  when  a  message  transmission  request  is  received  over  HLA,  the 
NET  TYPE  number  will  be  mapped  to  a  particular  net  type  description,  and  the  combination  of 
platform  source,  destination  and  net  type  will  be  used  to  find  an  operational  net  (if  it  exists). 
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Link- 16  terminals  support  a  variety  of  Access  Modes.  These  are  listed  in  Table  9  below.  When 
Operational  Nets  are  defined,  their  Access  Mode  must  be  specified.  Dedicated  Access  means 
that  a  particular  Operational  Net  has  only  one  transmitter.  In  Contention  Access,  all  Link- 16 
platforms  are  potentially  transmitters,  and  “contend”  for  access  to  the  net.  Dedicated  Slot  Reuse 
supports  pooled  bandwidth  capabilities. 


Link-16  Access  Modes 

Dedicated  Access _ 

Contention  Access _ 

Dedicated  Slot  Reuse 


Table  9  -  JTIDS/MIDS  Access  Modes 


Therefore,  in  order  to  handle  general  message  transmissions  requests  from  JSAF,  the  design  of 
the  enhanced  JTIDS  simulation  will  need  to  support  each  type  of  Access  Mode  whether  the 
message  goes  directly  through  a  net  or  through  the  SAR  functions.  This  is  a  new  design 
requirement  on  the  JTIDS  simulation  for  the  GIESim-JSAF  merger. 


5.6.2.5  Design  of  HLA  Transmission  Request  Handling 

In  the  enhanced  version  of  the  PSI  Link- 16  JTIDS  simulation  for  JSAF,  most  Link- 16  message 
transmissions  occur  as  a  result  of  requests  driven  externally  from  JSAF1.  Therefore,  the  existing 
JTIDS  internal  message  generation  logic  was  circumvented  and  replaced  by  routines  to  generate 
messages  based  on  HLA  stimuli. 

In  addition,  new  Operational  Net  selection  logic  was  designed  to  select  Operational  Nets  based 
on  the  platform  source,  destination  and  net  type.  Entity  ID  and  net  type  mapping  is  required  on 
message  input,  and  Entity  ID  mapping  is  required  on  response  to  JSAF.  Operational  Nets 
typically  have  many  destinations  and  the  nets  that  are  defined  for  JSAF  required  choices  in  this 
area.  In  order  to  simplify  the  interactions  with  JSAF  and  internal  logic  of  JSAF,  JSAF  will 
provide  a  single  destination  address  in  the  message  transmission  request.  This  meant  that  new 
logic  had  to  be  added  to  the  JTIDS  simulation  to  identify  when  the  particular  target  destination 
platform  specified  by  JSAF  has  received  the  message.  Figure  33  illustrates  many  of  these 
features. 

In  the  event  the  teams  decide  to  use  broadcast  Link- 16  messages,  e.g.,  for  PPLI  messages,  or 
want  all  recipients  on  an  Operational  Net  to  report,  JTIDS  will  support  a  destination  field  of  ‘O’. 
This  implies  that  all  destinations  in  an  operational  net  that  receive  the  message  will  respond  by 
the  generation  of  GIESIM  MSG  RCVD  interactions.  This  is  illustrated  in  Figure  34. 


1  Some  internally  generated  messages  could  be  turned  on  in  the  driven  JTIDS  system  to  provide  background  traffic. 
Note  that  internal  message  traffic  generation  in  the  JTIDS  simulation  is  currently  turned  OFF. 
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Figure  33  -  JTIDS  Internal  Message  Handling 


Note  that  messages  that  can  fit  into  the  available  capacity  of  the  chosen  Operational  Net  by-pass 
the  SAR  capability,  whereas  messages  that  will  not  fit  into  the  capacity  of  the  net  are  segmented 
by  the  JTIDS  SAR  capability. 


5.6.2.6  JTIDS  Message  Payload  and  SAR  Function  Design 

The  combination  of  (1)  the  JSAF  Message  ID,  (2)  Destination  Platform  ID,  and  (3)  Incoming 
Message  Latency  value  comprise  a  payload  of  information  that  must  be  sent  through  the  JTIDS 
simulation  so  that  it  can  be  reported  back  to  JSAF  on  message  reception,  and  must  be  preserved 
independently  of  whether  or  not  the  message  passes  through  the  SAR  capability. 
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This  JSAF-related  payload  must  therefore  be  passed  through  the  entire  JTIDS  simulation,  and 
constituted  a  required  design  change  to  the  PSI  JTIDS  simulation. 

The  version  of  the  JTIDS  that  was  used  in  the  GIESim  SAB  Demo  provided  SAR  capabilities 
that  were  designed  specifically  for  the  limited  scenario  that  was  being  run  in  the  demo.  In  order 
to  support  the  more  general  nature  of  the  communications  modeling  required  for  JSAF,  a  more 
robust  and  extensive  SAR  capability  was  required. 

The  design  of  the  new  SAR  capability  for  the  GIESim- JSAF  merger  was  based  on  the 
assumption  that  only  a  small  number  of  large,  image-related  messages  would  likely  be  in  transit 
at  any  one  time.  The  current  SAR  capability  is  therefore  limited  to  ten  outstanding  large 
messages  at  any  one  time. 


5.6.2.7  Design  of  HLA  Reporting  of  Message  Reception 

In  the  JTIDS  simulation,  when  a  message  is  sent  over  a  particular  Operational  Net,  the  message 
flows  through  the  simulation  and  all  platforms  that  are  designated  as  destinations  in  the 
Operational  Net  are  scheduled  to  receive  the  message.  If  conditions  are  appropriate  for 
reception,  e.g.,  strong  enough  signal  and  SNR  is  sufficient,  at  the  scheduled  time  of  arrival,  then 
the  message  is  “received”. 

In  the  enhanced  JTIDS  simulation,  a  receiving  platform  “host”  will  determine  if  its  ID  matches 
the  platform  destination  ID  sent  by  JSAF.  If  so,  then  a  response  HLA  GIESIMMSGRCVD 
interaction  is  built  for  sending  to  JSAF.  Note  that  a  JSAF  destination  ID  of  ‘O’  will  cause  all 
platforms  to  report  reception  of  the  message. 

To  build  the  response  message,  JTIDS  moves  the  JSAF  Message  ID  from  the  received  message 
payload  to  the  appropriate  field  in  the  GIESIM  MSG  RCVD  interaction.  JTIDS  then  puts  the 
entity-mapped  platform  ID  into  the  Destination  ID  field  of  the  HLA  interaction.  Finally  JTIDS 
determines  the  time  required  to  pass  the  message  through  the  simulation  and  adds  it  to  the 
incoming  latency  from  the  message  payload,  and  puts  the  updated  latency  value  in  the  HLA 
interaction.  Figure  33  and  Figure  34  illustrate  this. 
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5.7  GIESim-JSAF  Merger  M&S  Development 

This  section  provides  details  on  the  PSI  developments  required  for  the  GIESim-JSAF  merger. 


5.7.1  RTI-S  Development  &  Integration 

Conversion  of  PSI  GIESim  GSS-based  simulations,  and  testing  GSS  with  the  RTI-S  used  by 
JSAF  proved  to  be  rather  difficult,  and  ultimately  required  some  minor  (though  tricky) 
modifications  to  the  environment  of  GSS  itself.  Testing  was  done  with  the  HLA  Test  Driver 
(TESTDRV)  that  PSI  developed  in  2003  in  preparation  for  the  GIESim  SAB  Demo. 


5.7.1. 1  Changes  to  GSS 

Part  of  the  difficulty  in  using  RTI-S  involved  incorrect  (or  misleading)  statements  in  the  RTI-S 
read  me  file  that  implied  the  need  to  link  RTI-S  DLL  files  rather  than  library  files  (i.e.,  .lib  files). 
Furthermore,  the  file  naming  conventions  used  in  RTI-S  are  different  than  those  used  in  the 
DMSO  RTI.  Ultimately,  PSI  took  a  very  methodical  approach  to  isolating  factors  required  to 
make  the  RTI-S  work  with  GSS.  The  current  release  of  GSS  relies  on  “private”  system  files  at 
build  time  when  a  simulation  is  “prepared”.  Modifications  to  one  key  GSS  “internal”  file  were 
needed  to  get  GSS  to  run  with  the  RTI-S.  The  RTI  HOME  and  RTI  BUILD  TYPE 
environment  variables  used  by  GSS  were  modified  to  point  to  the  location  of  the  RTI-S  directory 
that  was  built  from  the  JSAF  release. 


5.7.1. 2  RTI-S  FOM  Requirements 

Once  we  had  RTI-S  working  under  GSS  and  in  our  test  driver  simulation,  it  was  easy  to  modify 
our  JTIDS  and  SAT  COM  simulations  to  RTI-S.  However,  we  did  discover  a  new,  unexpected 
characteristic  of  RTI-S. 

With  the  DMSO  RTI,  each  simulation  could  to  use  a  subset  of  the  largest,  superset  FOM  in  a 
multi- simulation  system,  and  all  that  mattered  was  that  the  FOMs  functionally  matched. 
However,  the  RTI-S  was  much  more  demanding.  Not  only  do  the  FOMs  need  to  match 
functionally,  they  also  need  to  match  physically.  RTI-S  performs  a  check-sum  on  the  FOMs  and 
fails  to  connect  if  the  FOMs  do  not  have  the  same  check-sum.  Figure  35  illustrates  this. 
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These  FOMs  match  functionally,  but  not  physically.  They  have  different  check-sums. 


Figure  35  -  Two  FED  files  -  Functionally  though  Physically  Different 


With  the  realization  that  all  GIESim-JSAF  simulations  needed  to  run  with  the  exact  same  FOM 
(.fed  file),  PSI  determined  that  it  needed  to  test  with  the  same  FOM  that  was  planned  for  use  with 
the  GIESim-JSAF  merger.  This  FOM  used  the  Millennium  Challenge  02  (MC02)  FOM  with  the 
GIESim  HLA  Interactions  added  to  it.  This  combined  FOM,  called  MC02plus  and  built  by 
SAIC,  was  converted  by  PSI  to  the  required  FED  (Federation  Execution  Details  File)  format 
using  the  DMSO  Object  Model  Development  Tool.  PSI  then  successfully  tested  the  GIESim.fed 
FOM  with  our  simulation  components. 

With  this  success,  all  the  PSI  GIESim  SAB  Demo  components  were  modified  for  RTI-S  and 
installed  in  the  GIESim  and  JSAF  labs  in  Rome. 

Note  that  each  time  a  GSS-based  simulation  using  HLA  is  re-prepared,  i.e.,  re-built,  a  new  local 
FED  file  is  generated.  This  FED  file  is  based  on  all  the  HLA  interactions  used  in  the  GSS 
simulation.  Since  RTI-S  requires  that  all  federates  use  the  same,  super-set  FOM,  the  GSS 
generated  FED  file  must  be  replaced  by  the  full  FOM,  in  this  case,  the  MC02plus_v4.fed  file. 
This  is  a  minor  nuisance,  and  requires  that  a  copy  of  the  target  FED  file  be  either  kept  in  the 
simulation  directory,  or  moved  into  the  simulation  directory  and  renamed  GIESIM.fed. 
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5.7.2  JTIDS  Development  for  GIESim-JSAF  Merger 

This  section  provides  detailed  descriptions  of  the  developments  in  JTIDS  that  were  accomplished 
for  the  GIESim-JSAF  merger.  An  overview  of  these  developments  and  changes  to  JTIDS  is  first 
provided,  and  the  development  of  more  discrete  changes  and  new  models  are  then  described. 
Note  that  to  realize  operations  with  JSAF,  the  JTIDS  simulation  was  designed  to  act  either  as  a 
“driver”  surrogate  for  JSAF  to  support  testing,  or  as  the  JTIDS  communications  messaging 
“server”  or  “driven”  JTIDS  system  for  JSAF. 


5.7.2.1  Overview  of  JTIDS  Developments  for  JSAF 

Figure  36  show  the  full  GSS  CAD  drawing  of  the  JTIDS  simulation  that  will  be  used  in  the 
merger.  Several  parts  of  the  simulation  are  highlighted  and  numbered  in  order  to  focus  on  key 
areas  that  were  affected  by  the  design  requirements  for  the  GIESim-JSAF  merger. 


JTIDSSIM 


’ Not  used  in 
GIESim-JSAF 


Models 
Modified  for 
GIESim-JSAF 


Figure  36  -  Enhanced  JTIDS  Simulation  for  GIESim-JSAF  Merger 
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Models  that  are  outlined  by  heavy  blue  lines  indicate  hierarchical  models  that  were  modified  to 
support  the  design  requirements.  The  hierarchical  model  outlined  in  orange  is  a  collection  of 
new  models  that  were  developed  specifically  for  the  merger.  Quite  a  number  of  design  changes 
and  developments  were  required  for  the  merger.  The  changes  to  the  numbered  models  are  as 
follows: 

1 .  The  GIESim  HLA  Interface  model  was  modified  to  support  the  addition  of  the 
NETTYPE  field  to  the  GIESIM  MSG  SEND  interaction.  This  modification  is  detailed 
in  a  subsequent  section. 

2.  The  HOST  model  of  the  JTIDS  simulation  required  a  number  of  modifications  to  support 
external  transmission  requests  and  to  report  receipt  of  a  message  over  an  Operational  Net. 
In  particular,  the  internal  JTIDS  message  data  structure  had  to  be  modified  to  support  the 
payload  of  the  JSAF  Message  ID,  Destination  Address  and  Latency  values.  This  data 
structure  change  “percolated”  through  many  parts  of  the  simulation.  More  detail  on  these 
changes  is  provided  further  on  in  this  report. 

3.  The  JTIDS  data  structure  changes  for  the  JSAF  message  payload  also  required  many 
changes  within  the  JTIDS  Terminal  model. 

4.  The  JSAF_INTERFACE  is  a  new  hierarchical  model  that  handles  many  of  the  details  of 
the  simulation  interface  to  JSAF  and  required  hooks  into  the  rest  of  the  enhanced  JTIDS 
simulation.  This  model  development  is  detailed  in  a  separate  section. 

5.  The  GIESIM  GATEWAY  model  was  developed  for  the  GIESim  SAB  Demo,  and  does 
not  apply  to  the  GIESim-JSAF  merger.  The  Control  Specification  of  the  JTIDS 
simulation  was  modified  such  that  this  model  is  no  longer  exercised. 

6.  The  IPSERVERMODEL  was  also  developed  to  support  the  GIESim  SAB  Demo,  and 
is  no  longer  exercised  in  the  JTIDS  simulation. 


5.7.2.2  HLA  Interface  Modifications 

Figure  37  indicates  changes  to  the  models  in  the  HLA_INTERFACE  hierarchical  model.  The 
primary  development  was  the  addition  of  the  NET  TYPE  field  to  the  GIESIM  MSG  SEND 
HLA  interaction.  Red  stars  in  Figure  37  indicate  GSS  resources  that  were  modified  for  the 
addition  of  this  new  field.  Associated  processes  were  also  modified  to  support  this  change. 

The  processes  PUBLISHSENDMESSAGES  and  PROCESSRECMSGSEND  were 
modified  to  support  the  ability  of  the  JTIDS  simulation  to  either  act  as  a  surrogate  for  JSAF  or  as 
a  recipient  of  JSAF  message  transmission  requests. 
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Figure  37  -  Modification  to  HLA  Interface 


5.7.2.3  New  JTIDS  Model  Development  for  JSAF 

Figure  38  shows  the  detailed  GSS  drawing  for  the  JSAF_INTERFACE  model  that  was 
developed.  This  model  “encapsulates”  most  of  the  simulation  interfacing  requirements  for 
operation  with  JSAF,  and  for  tying  into  the  internals  of  the  JTIDS  simulation.  The  purpose  and 
function  of  each  of  the  models  within  the  JSAF  INTERFACE  model  are  as  follows: 


5.7.2.3.1  DRIVER_COM_MODEL 

When  the  JTIDS  simulation  is  in  “driver”  mode,  Link- 16  platforms  are  moved  along  movement 
paths  that  they  are  associated  with  in  the  scenario  file.  This  model  handles  part  of  the  JSAF 
surrogate  functions,  and  is  responsible  for  sending  test  HLA  position  updates  for  platforms  when 
they  move. 
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S.7.2.3.2  DRIVE  MODEL 


This  model  provides  functions  for  both  the  “driver”  and  “driven”  modes  of  the  enhanced  JTIDS 
simulation. 

In  driver  mode,  it  sets  the  HLA  message  rate  for  sending  GIESIMENTITYSTATE  position 
updates.  A  panel  is  provided  to  set  the  update  rate.  This  capability  was  developed  to  test  the 
expected  range  of  position  updates  coming  from  JSAF  to  verify  that  the  driven  version  of  JTIDS 
could  handle  the  update  rate.  Internal  JTIDS  simulation  coordinates  are  mapped  to  LAT  LON 
representation  before  being  sent. 
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Figure  38  -  New  Models  for  Interface  to  JSAF 


In  both  driver  and  driven  modes,  the  DRIVER  MAPS  between  LAT  LON  coordinates  and 
internal  coordinates  used  within  JTIDS. 
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5.7.2.33  REMOTE  ENTITY  MODEL 

This  model  handles  the  mapping  between  internal  JTIDS  platform  IDs  and  hashed  values  of 
platform  IDs  that  are  exchanged  between  JSAF  and  JTIDS.  This  model  calls  a  hashing  function 
on  the  platform  names  to  create  the  hashed  platform  values. 


5.7.23.4  NETTYPE  DATA  MODEL 

This  model  reads  the  NETMAPFILE  that  was  generated  by  the  PSI  Link- 16  Planning  Tool,  and 
builds  a  table  of  net-type  labels  and  their  associated  enumeration  for  use  in  other  models. 


5.7.23.5  SAF  INTERCOMM  MODEL 

This  is  the  main  model  for  JTIDS  when  it  is  being  driven  by  JSAF  for  JTIDS  message 
transmission  requests.  The  fields  in  the  received  GIESIM  MSG  SEND  HLA  interaction  are 
interpreted  by  this  model.  Entity  IDs  are  reversed  mapped  to  internal  sending  and  receiving 
platforms  IDs,  and  the  Net  Type  value  is  mapped  to  a  net  type  label  or  string. 

The  sending  and  receiving  platforms  and  the  net  type  label  are  fed  into  the  FIND  NET  process 
to  locate  an  Operational  Net  to  send  the  message  over.  The  JDRVSENDMESSAGE  process 
sends  the  message  to  the  appropriate  process  in  the  SAFSENDMODEL  based  on  the  Access 
Type  of  the  Operational  Net  selected.  If  the  size  of  the  JSAF  message  is  too  big  for  the  capacity 
of  the  chosen  Operational  Net,  then  the  JSAF  message  is  sent  through  the  SAR  functions  in  the 
JTIDS  simulation.  SAR  functions  are  covered  in  the  next  section.  If  no  Operational  Net  can  be 
found,  then  the  message  transmission  request  is  dropped. 


5.7.23.6  SAF  SEND  MODEL 

This  model  contains  two  processes  that  build  and  send  JTIDS  data  structures  through  the  JTIDS 
simulation.  One  process  is  used  for  Dedicated  Access  Mode,  and  the  other  is  used  for 
Contention  Access  and  Dedicated  Slot  Reuse  Access  Mode. 

Each  process  will  build  an  internal  JTIDS  message  transmission  data  structure  that  will  include 
the  JSAF  data  payload,  i.e.,  destination  platform,  JSAF  message  ID,  latency. 

5.7.23.7  SAF  RECEIVER  MODEL 

This  model  is  used  when  a  JSAF  message  has  been  successfully  received  over  an  Operational 
Net  within  the  JTIDS  simulation  when  it  is  being  driven  by  JSAF.  The  model  builds  a 
GIESIM  MSG  RCVD  HLA  interaction  that  includes  the  entity-mapped  platform  ID  of  the 
receiving  platform,  JSAF  message  ID,  and  accumulated  latency,  i.e.,  the  latency  through  the 
JTIDS  transmission  added  to  the  incoming  latency  that  was  sent  in  the  JSAF  message  request. 
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S.7.2.3.8  HLA  RECEIVER  MODEL 


This  model  is  used  for  debugging  when  the  JTIDS  simulation  is  being  used  as  a  driver.  This 
model  handles  display  of  GIESIMMSGRCVD  interactions  from  the  driven  system. 


5.7.2.4  Internal  Host  and  Terminal  Models  Changes  to  Support  JSAF 

Figure  39  shows  some  drawing  details  for  parts  of  the  JTIDS_HOST  model,  particularly  the 
HOST  model  that  contains  the  HOSTMESSAGEGENERATOR  and  FREE  TEXT  model,  and 
HOSTOUTBOUNDQUEUE  and  HOSTINBOUNDQUEUE  models.  Figure  39  also 
indicates  the  connections  between  the  HOST  model  and  the  LINK-16MODEL.  This  section 
will  describe  the  model  developments  that  were  required  to  support  the  GIESim-JSAF  merger. 


Figure  39  -  Host  Model  Changes  for  JSAF  Payload  and  SAR  Functions 


5.3.2.4.1  Additions  to  Outbound  and  Inbound  Data  Structures 

The  HOST  OUTBOUND  QUEUE  resource  contains  a  data  structure  that  is  sent  through  the 
Link-16  simulation,  i.e.  the  LINK16MODEL.  Fields  in  this  data  structure  encode  the  sending 
platform,  the  Operational  Net  number  and  its  Access  Mode,  a  list  of  destination  platforms,  and 
other  information  required  by  the  Link- 16  model,  and  needed  for  measuring  performance  of  the 
network.  The  HOST  INBOUND  QUEUE  resource  contains  a  similar  data  structure  that  is 
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loaded  whenever  a  message  is  received.  In  particular,  the  ID  of  the  receiving  platform  is 
specified  for  use  by  the  HOSTMESSAGEPROCESSOR  process  that  is  called  by  the  Link- 16 
Model  whenever  it  receives  a  message. 

For  the  operation  of  JTIDS  with  JSAF  several  fields  were  added  to  these  data  structures.  As 
noted  in  an  earlier  section  of  this  report,  fields  that  were  added  to  support  the  JSAF  payload 
include:  (1)  JSAF  Message  ID,  (2)  Destination  Platform  ID,  and  (3)  latency.  Three  additional, 
undedicated  fields  were  also  added  for  future  use.  In  addition,  an  existing  MESSAGE_SOURCE 
data  attribute  was  modified  to  support  a  “SAF”  tag  so  that  JSAF  related  messages  could  get 
special  handling. 

The  data  structures  from  the  inbound  and  outbound  queues  are  replicated  in  many  places 
throughout  the  JTIDS  simulation.  The  red  stars  in  Figure  39  indicate  some  of  the  resources  that 
use  these  data  structures.  Over  a  dozen  resources  in  the  JTIDS  simulation  that  use  parts  of  these 
data  structures  were  modified  for  the  merger  with  JSAF. 


5.7.2.4.2  Modifications  to  the  HOST_MESSAGE_PROCESSOR 

When  a  Link- 16  message  is  received  in  the  LINK16MODEL,  the 

HOST  MESSAGE  PROCESSOR  in  the  HOST  model  is  called  to  handle  it.  This  HOST  model 
process  was  modified  to  look  for  the  “SAF”  tag  in  the  received  data  structure  in  the 
HOSTINBOUNDQUEUE.  If  the  message  is  tagged  as  a  SAF  message,  then  the 
GETSAFMESSAGE  process  in  the  SAFRECEIVEMODEL  of  the  JSAFINTERFACE  is 
called  for  further  handling.  See  Section  3.2. 3. 7. 


5.7.2.4.3  New  HOSTMESSAGEGENERATOR  Process 

Processes  within  the  HOST  MESSAGE  GENERATOR  model  are  used  to  build  various 
outbound  messages.  A  new  process,  the  GIE_MANUAL_NET_GEN,  was  added  as  an  interface 
to  the  HOST  MESSAGE  GENERATOR  process,  and  is  called  from  the  SAF  SEND  MODEL. 


S.7.2.4.4  New  FREETEXT  SAR  Model 

For  the  GIESim  SAB  Demo,  SAR  models  were  added  to  JTIDS  to  support  segmentation  and 
reassembly  of  specific  image  related  messages.  For  JTIDS  operation  with  JSAF,  a  more 
generalized  version  of  SAR  was  needed.  The  FREE  TEXT  model  shown  in  Figure  39  handles 
the  JTIDS  SAR  functions  for  the  GIESim-JSAF  merger.  This  model  is  invoked  for  JSAF 
messages  that  will  not  fit  as  a  whole  into  the  capacity  of  the  Operational  Net.  The  model  will  use 
nets  that  are  defined  to  use  the  Link- 16  Free  Text  message  type.  If  all  segments  of  a  message  are 
not  received  within  a  time-out  period  by  the  FREE  TEXT  model,  it  will  drop  the  JSAF  message. 
FREE_TEXT  currently  supports  only  Contention  Access.  This  model  will  be  enhanced  to 
support  the  other  Access  Modes  required  for  JSAF,  particularly  Dedicated  Access  mode. 
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5.8  M&S  Testing 


This  section  describes  testing  that  was  performed  internal  to  PSI,  and  interoperability  testing  that 
was  done  to  ensure  proper  operation  of  the  PSI  simulation  components  the  GIESim-JSAF 
merger. 

5.8.1  RTI-S  Testing 

Once  the  driver  simulation,  TESTDRV,  was  built  successfully,  it  could  be  tested.  Testing 
disclosed  the  need  to  either  relocate  the  RTI-S  DLL  files  to  the  Windows  directory  or  to  modify 
the  environment  variables  to  include  the  RTI-S  DLLs  in  the  path.  The  latter  approach  is 
preferred  and  is  the  one  that  PSI  ultimately  adopted. 

Figure  40  illustrates  initial  testing  of  the  RTI-S  with  the  GSS  TEST  DRV  simulation.  Several 
instances  of  TEST  DRV  were  launched  and  we  verified  correct  operation  of  the  simulations. 


Figure  40  -  Single  PC  Test  of  RTI-S  with  GSS 


Figure  41  shows  a  multi-PC  test  case  that  was  used  to  verify  correct  operation  of  the  RTI-S  and 
multiple  instances  of  TEST  DRV  running  on  two  PCs  over  a  local  LAN  connection. 


Figure  41  -  Multiple  PC  Test  of  RTI-S  with  GSS 


55 


As  each  instance  of  the  RTI-S  simulation  started,  the  RTI-S  generated  some  diagnostic  messages 
that  were  deemed  to  be  benign.  In  each  of  the  test  cases  shown  above,  PSI  verified  that 
messages  were  correctly  published  and  subscribed  to  across  instances  of  the  TESTDRV 
simulation.  We  also  terminated  instances  of  TEST  DRV  abnormally  to  determine  the  impact  on 
RTI-S  and  on  the  other  running  instances  of  TEST  DRV.  Whereas  the  DMSO  RTI  became 
unstable  when  a  Federate  did  not  “resign”  gracefully,  the  RTI-S  continued  to  function  flawlessly. 
This  is  likely  due  to  the  fact  that  RTI-S  is  nodeless,  whereas  the  DMSO  RTI  requires  and 
depends  on  a  centralized  RTI  that  supports  all  “connected”  Federates. 

PSI  communicated  success  with  RTI-S  by  email  to  the  team  on  May  26.  Future  releases  of  GSS 
will  support  both  the  RTI-S  and  DMSO  RTI  conventions. 


5.8.2  GIESim-JSAF  JTIDS  Testing 

Recall  that  the  enhanced  JTIDS  simulation  that  PSI  built  for  the  merger  can  be  used  either  as  a 
driver  surrogate  for  JSAF  or  as  the  JTIDS  communications  modeling  and  simulation  system 
being  driven  by  JSAF.  Initial  testing  of  the  enhanced  JTIDS  simulation  was  performed  internal 
to  PSI  using  both  capabilities  of  the  enhanced  version  of  JTIDS.  Figure  42  shows  this  test 
configuration. 


Figure  42  -  Internal  PSI  Test  Configuration  for  Testing  the  GIESim-JSAF  JTIDS  Simulation 


Both  the  JTIDS  test  driver,  and  driven  JTIDS  simulation  used  the  same  network  files,  and  force 
scenario.  The  JSAF  surrogate  system  also  had  movement  profiles  or  paths.  Both  systems  used 
the  same  GIESim  FOM  (GIESIM.fed).  In  driver  mode,  JTIDS  reads  in  the  EntityMap  and 
NetTypeMap  files  as  JSAF  is  expected  to  do.  The  driven  version  of  JTIDS  performs  the  entity 
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mapping  hash  functions  internally,  and  maps  the  NETTYPE  field  received  from  the  HLA 
GIESIM  MSG  SEND  interaction. 


5.8.2.1  Position  Updates 

The  PSI  developed  Korea_5  and  Korona  scenarios  were  used  to  verify  correct  operation  of  the 
Entity  Mapping  functions  and  position  updates  of  platforms  using  various  HLA  position  update 
rates  from  the  JTIDS  Driver.  Correct  operation  was  verified  by  visually  observing  position  and 
movements  of  selected  platforms  in  each  version  of  JTIDS  that  was  running.  Aside  from  a  slight 
delay  in  position,  the  driven  JTIDS  simulation  performed  as  desired. 

During  inspection  of  platform  positioning  code,  it  was  determined  that  the  driver  system  was 
sending  internal,  relative  XYZ  coordinates  rather  than  actual  LAT  LON  values.  This  worked 
because  the  receiving  JTIDS  system  was  using  these  values  directly  instead  of  converting  to 
internal  coordinate  from  the  received  LAT  LON  value. 

Therefore,  the  driver  system  was  modified  to  convert  output  values  to  LAT  LON  and  conversely, 
position  updates  received  over  HLA  in  the  driven  mode  were  converted  from  LAN  LON  to 
internal  representations  used  in  JTIDS.  This  demonstrates  the  value  of  building  a  test  driver 
prior  to  interoperability  testing  with  JSAL. 


5.8. 2.2  Message  Transmission  Testing 

The  PSI  Korea_5  scenario  and  its  associated  network  file  were  initially  used  to  test  the  message 
transmission  capabilities  of  JTIDS  for  the  GIESim-JSAL  merger. 

Testing  proceeded  in  stages  and  culminated  in  testing  of  messages  from  all  “Wow”  platforms  in 
the  Korona- Wow  scenario. 

In  the  driver  system,  HLA  GIESIM_MSG_SEND  interactions  were  manually  constructed  by 
using  the  internal  test  driver  interface  that  was  imported  from  the  GIESim  SAB  Demo  version  of 
JTIDS.  This  approach  provided  a  very  controlled  way  of  sending  message  transmission  requests 
to  the  driven  JTIDS  system,  and  we  could  specify  the  message  source,  destination  and  net  types 
to  force  transmission  through  selected  Operational  Nets.  This  allowed  us  to  test  the  code  that 
supported  each  type  of  Link- 16  Access  Modes.  Messages  using  both  valid  and  invalid  data  were 
sent  to  verify  correct  behavior  in  the  Driven  JTIDS  simulation. 

Initial  testing  was  directed  at  nets  that  used  Dedicated  Access  Mode,  and  verified  correct 
operation,  and  correct  response  from  the  driven  system,  since  we  could  view  the  HLA 
GIESIM  MSG  RCVD  interaction  in  the  JSAF  surrogate  that  was  sent  by  the  driven  JTIDS 
simulation  when  the  message  was  received  by  the  target  JTIDS  platform. 
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Initial  testing  used  message  sizes  that  did  not  require  message  segmentation  and  reassembly 
(SAR).  Subsequent  manual  testing: 


•  Chose  nets  that  use  the  other  Access  Modes. 

•  Use  message  sizes  that  require  SAR  support. 


5.4.3.2.2  Auto-Generated  Message  Testing 


When  JTIDS  is  used  with  the  actual  JSAF  system,  message  requests  of  different  types  and  sizes 
are  expected  to  occur  at  high  volume.  In  order  to  test  the  expected  mix  and  load  of  traffic  in- 
house,  PSI  used  the  traffic  generation  capability  built  into  JTIDS.  This  capability  is  enabled 
when  JTIDS  is  being  used  in  the  driver  mode,  and  disabled  when  JTIDS  is  being  driven. 

JTIDS  auto-generation  of  messages  can  be  enabled  for  all  net  type,  i.e.,  access  modes.  Different 
modulation  schemes  can  be  used  to  vary  message  generation  rates. 

Testing  of  the  driven  JTIDS  simulation  for  the  GIESim-JSAF  merger  took  place  prior  to  the 
interoperability  testing  that  occurred  in  AFRL  Rome  in  November. 
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5.8.3  JSAF  Interoperability  Testing 


Interoperability  testing  of  the  merged  GIESim/JSB-RD  software  took  place  over  an  extended 
interval  due  to  initial  interoperability  problems  that  are  ultimately  solved  by  the  team,  resulting 
in  successful  interoperability. 


5.8.3.1  Interoperability  Testing  in  AFRL  Rome 

Initial  interoperability  testing  between  JSAF  and  JTIDS  took  place  on  16  and  17  Nov  2004  in  the 
JSB-RD  JSAF  lab  in  AFRL  Rome.  The  test  configuration  is  shown  in  Figure  43.  The  Korona- 
Wow  scenario  was  used  in  the  interoperability  tests. 

JSAF  used  movement  paths  that  were  modified  versions  of  the  movement  paths  in  the  Korona 
scenario.  The  Link-16  platform  force  composition  was  the  same.  Operational  Networks 
designed  by  PSI  to  meet  the  JSAF  communications  requirements  for  the  scenario  were  used. 


Figure  43  -  JSAF-JTIDS  Interoperability  Test  Configuration. 


JSAF  uses  the  EntityMap  and  NetType  files  provided  by  PSI. 

PSI  installed  GSS  Release  10.3.7  and  the  JTIDS  Driver  and  Driven  versions  on  one  of  the  JSAF 
PCs  assigned  to  PSI.  While  another  team  continued  to  work  the  modifications  to  JSAF,  PSI: 

■  Modified  GSS  to  support  RTI-S 

■  Installed  RTI-S  on  the  target  PC  and  modified  the  required  environment  variables: 


59 


o  RTI_HOME=  C:\RTI-S\ 
o  RTI_BUILD_TYPE=Win2000-VC6 

o  Added  C:\RTI-S\Win2000-VC6\lib\  to  the  system  PATH  variable. 

■  Began  testing  the  JTIDS  systems  (driver  and  driven)  on  the  JSAF  PC. 

Initial  testing  disclosed  a  conflict  between  the  PSI  HLA  Interactions  and  the  MC02plus  FOM 
that  caused  RTI-S  to  hang.  The  problems  were  found  quickly  and  fixed.  The  MC02plus  FOM 
had  to  be  modified  to  support  a  new  parameter  field,  NET  ID,  at  the  end  of  the 
GIESIM_MSG_RCVD  HLA  interaction.  Also,  the  name  of  the  parameter  field  that  the  team  had 
agreed  to  add  to  the  GIESIM  MSG  SEND  interaction  differed  between  the  PSI  implementation 
and  the  MC02plus  FOM.  The  FOM  was  modified  to  use  NET  TYPE  NUMBER  rather  than 
NET  TYPE.  These  name  changes  were  coordinated  and  agreed  to  by  Jerry  Reaper  who  was 
handling  JSAF  modifications. 

The  revised  MC02plus.omt  FOM  was  renamed  to  MC02plus_v4.omt,  and  the  DMSO  HLA  tool 
was  used  to  create  a  new  fed  file  for  use  with  JTIDS  and  JSAF  -  this  file  was  named 
GIESIM.fed. 

Ultimately,  and  for  the  sake  of  safety  and  reproducibility,  PSI  decided  to  re-prepare,  i.e.,  rebuild 
or  recompile,  both  JTIDS  versions  -  driver  and  driven.  Also,  since  JSAF  was  not  ready  for 
testing,  PSI  decided  to  test  the  newly  built  versions  across  two  JSAF  PCs. 

Finally  we  had  an  exact  copy  of  the  same  directory  structure  GIESIM-JSAF,  shown  in  Figure  44, 
created  on  both  PCs  as. 


E  GIESIM-JSAF 
"  O  Driven 

[+  -0  JTIDS- JSAF 
Q  TERR_DATA 
$Q  Driver 
|  E&  O  JTIDS 

Q  TERR_DATA 
E  O  Maps 
Q  XFER 

Figure  44  -  GIESIM-JSAF  Directory  Structure 

Executing  JTIDSSIM2D.EXE  in  the  GIESIM-JSAF/Driver/JTIDS  directory  launched  the  JTIDS 
driver,  and  executing  JTIDSSIM2D.EXE  in  the  GIESIM-JSAF\Driver\JTIDS-JSAF  directory 
launched  the  driven  version  of  JTIDS  for  use  with  JSAF. 

The  installation  and  operation  was  first  tested  using  one  PC  to  launch  the  driven  JTIDS  version 
and  the  other  PC  to  launch  the  driver  JTIDS  version,  then  vice  versa.  Each  case  tested  100%. 
Platform  position  updates  were  sent  from  the  driver  system  and  received  at  and  responded  to 
correctly  by  the  driven  system.  The  graphic  displays  were  used  to  compare  platform  positions  to 
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verify  correct  operation.  The  HLA  GUI  Control  panel  that  is  provided  with  each  JTIDS 
simulation  (shown  below  in  Figure  45)  was  used  to  send  an  HLA  interaction  from  the  driver 
JTIDS  system  to  the  driven  JTIDS  system.  This  interaction  was  to  request  transmission  from 


the  SOF  to  the  lead  FI 5. 


Figure  45  -  HLA  GUI  Control  Panel  in  JTIDS  Simulations 


Several  more  tests  verified  correction  operation  of  both  PSI  JTIDS  simulations  on  either  PC. 

Unfortunately,  we  were  unable  to  exchange  messages  with  the  modified  JSAF  running  on  a 
Linux  PC.  The  PSI  simulations  could  not  see  any  messages  from  JSAF,  nor  could  JSAF  see  any 
messages  from  JTIDS.  Another  Linux  workstation  was  able  to  see  packets  coming  from  JTIDS. 

Several  days  later  it  was  determined  that  JSAF  was  not  actually  publishing  HLA  interactions,  nor 
was  it  responding  to  interactions.  At  the  time  (12/6/04),  work  was  still  underway  to  get  the 
modifications  on  JSAF  working  to  support  communications  handling  by  PSI  JTIDS. 

Over  the  next  few  weeks  the  JSAF  modifications  developed  by  SAIC  enabled  sending  and 
receiving  HLA  messages  by  JSAF.  However,  since  there  was  some  uncertainty  on  how  both 
systems,  JSAF  and  PSI  JTIDS,  were  handling  messages  associated  with  the  FOM,  PSI  agreed  to 
add  additional  diagnostic  messages  to  the  PSI  JTIDS  simulation  to  verify  correct  reception  of, 
and  generation  of  HLA  messages. 


5.8.3.2  Enhanced  Diagnostics  for  Interoperability  Testing 

The  initial  versions  of  the  PSI  JTIDS  simulation  contained  a  certain  number  of  diagnostic  data 
printouts.  These  diagnostics  had  been  removed  to  avoid  any  background  overhead.  Once  PSI 
and  SAIC  had  determined  that  some  HLA  messages  might  be  scrambled,  possibly  due  to 
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different  interpretations  of  the  FOM,  PSI  agreed  to  heavily  implement  both  the  Driver  and 
Driven  JTIDS  simulation  with  diagnostic  messages.  Diagnostics  were  added  at  the  HLA  receive 
and  transmit  points  in  both  simulations.  This  allowed  SAIC  to  examine  received  and  sent  HLA 
messages  in  detail.  Furthermore,  the  internal  logic  for  choosing  platforms  based  on  ENTITYID 
and  networks  via  NET_TYPES  was  also  instrumented  so  program  flows  in  the  simulations  could 
be  traced.  In  addition,  the  code  was  modified  to  ensure  that  the  HLA  GUIs  reflected  all  HLA 
messages  sent  and  received.  Diagnostics  were  added  in  a  manner  that  allows  them  to  be  easily 
turned  off. 

Also,  further  testing  by  PSI  revealed  that  the  hashing  function  used  to  generate  ENTITYIDs  did 
not  always  give  consistent  values.  Therefore,  PSI  rewrote  the  hashing  code  in  GSS  and  verified 
correct  and  consistent  operation. 

The  next  few  tables  and  figures  illustrate  some  of  the  diagnostic  changes  PSI  added  to  support 
interoperability  testing.  First,  Table  10  shows  the  ENTITY  IDs  for  the  “Wow”  scenario 
components  using  the  new  hashing  algorithms.  Note  that  the  numbers  on  the  right  side  of  Table 
10  list  the  internal  platform  IDs  within  the  PSI  JTIDS  simulations. 


Table  10  -  Wow  Scenario  Entity  IDs  in  File  ENTITY.OUT 


018783 

SOF_l 

091 

021052 

Target-wowl 

092 

018721 

SAM_POPUP 

093 

019691 

SAM_POPUP2 

094 

019712 

SAM  POPUP3 

095 

019733 

SAM  POPUP4 

096 

029192 

FI  5  WA04 . Lead 

097 

029768 

F15_WA04 .2 

098 

029789 

F15_WA04 . 3 

099 

029810 

FI 5  WA04.4 

100 

Table  11  -  NET  TYPES  for  the  Korona-Wow  JTIDS  Network  in  File  NETMAPFILE.TXT 

001  RTT_B 

002  AIRCONTROLJJPLINK 

003  ELECTRONIC  WARFARE 

004  FTR_TO_FTR_TARGET 

005  ENGAGEMENT_COORD 

006  RE S I DU AL_MS G 

007  NEEDLINE 

008  PPLI_A 

009  VOICE_l 

010  VIDEO_DOWNLINK 

Oil  PPLI_B 

012  MISSION_MGT 

013  SURVEILLANCE 

014  THREAT  WARNING 

015  MISSION  CONTROL 

016  ENGAGEMENT  STATUS 
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The  NETTYPE  numbers  shown  in  bold  in  Table  1 1  list  the  new  networks  that  PSI  defined  for 
the  Korona-Wow  scenario.  The  ENTITY  IDs  and  NET  TYPEs  are  used  in  the  examples  that 
follow. 


The  left  side  of  Figure  46  shows  the  GUI  that  was  used  to  build  a  GIESIMENTITYSTATE 
HLA  message  in  the  JTIDS  Driver  simulation.  After  the  message  is  published,  i.e.,  sent  over 
HLA,  it  was  received  by  the  PSI  JTIDS  Driven  simulation.  The  right  side  of  Figure  46  shows 
the  details  of  the  received  interaction  and  diagnostics  on  the  subsequent  platform  look-up  in  the 
Driven  JTIDS  simulation.  The  diagnostic  message  verified  correct  reception  of  this  HLA 
message,  and  that  the  correct  platform  was  found.  Both  valid  and  invalid  Entity  IDs  were  sent  to 
verify  correct  operation  of  the  driven  JTIDS  simulation. 


GIESIM_ENTITY_STATE 
Sent  by  Driver  Simulation  GUI 


GIESIM_ENTITY_STATE  Diagnostics 
Displayed  in  Command  Window  of 
Receiving  JTIDS  Driven  Simulation 


RECEIVED  GIESIM  ENTITY  STATE 


ENTTITY_TYPE= 
DOMAIN= 
COUNTRY  CODE= 
CATEGORY= 
SUBCAT= 

ENTITY_ID= 

HEADING= 

LAT= 

LON= 

ALT= 

EFFECTS= 


1 

2 

3 

4 

5 

29192 

.  4500000E+002 
.  3 900000E  +  002 
.  1248942E  +  003 
.  1000000E  +  004 
0 


LOOKING  UP  KEY:  97  F15_WA04 . Lead 

FOUND  PLATFORM  KEY:  97  F15_WA04 . Lead 

PLATFORM_REL_X:  .  4247747E+005 
PLATFORM_REL_Y :  . 5947803E+006 

PLATFORM_REL_Z :  .  1 0 0 0 0 0 0E  +  0 0 4 

PLAT  KEY  BEFORE  REPLACE:  97 


Figure  46  -  ENTITY  STATE  Message  Sent  and  Received 


Next  the  JTIDS  Driver  GUI  shown  in  Figure  47  was  used  to  send  a  GIESIM  MSG  SEND 
interaction  to  the  PSI  JTIDS  Driven  simulation.  Upon  receipt,  the  diagnostics  in  the  command 
window  of  the  JTIDS  Driven  simulation  show  the  diagnostic  messages  in  Table  12. 
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Figure  47  -  GIESIMMSGSEND  Send  GUI  Panel  is  Used  to  Build  a  Message 


Table  12  -  Received  GIESIM  MSG  SEND,  Transmission,  and  Publish  Diagnostics 


RECEIVED  GIESIM  MSG  SEND  INTERACTION  FROM  123 


RECV  INTERACTION  #  3  *** 

GIESIM  MSG  SEND  INTERACTION  RECEIVED  AT 


SEND_FED_ID: 
SEND_ENTITY_ID: 
RECV_FED_ID : 
RECV_ENTITY_ID : 
SEND_MSG_ID : 
MESSAGE  LENGTH: 
SEND_CUM_LATENCY : 
SEND  NET  TYPE: 


123 

18783 

321 

29192 

344 

1 

* lOOOOOOE+OOO 
14 


12100106 


DRIVEN  JTIDS  RECEIVED  REMOTE  MESSAGE  SEND  REQUEST 
FINDING  NET. . .  14 

GIESIM  MSG  SEND  FOUND  SENDER  PLATFORM  TO  MATCH  18783  ->  91  SOF  1 


GIESIM_MSG_SEND  FOUND  RECEIVER  PLATFORM  TO  MATCH  29192  ->  97  F15_WA04 . Lead 

GHAWK_2_6  1 9 

F15_WA04 . Lead  97 

F15_WA04 . 2  98 

F15_WA04 . 3  99 

F15_WA04 . 4  100 

SENDING  DED_REL  MESSAGE  TO  97 

ACCUMTIME:  11 658 9999999850 9E+004 

GENTIME:  *11660000000000001+004 

DESTI:  97 

SCHEDULE_T IME  =  .  8242733E-001 

NUMBER_DESTS  =  5 

MSG_ID :  344 

LATENCY:  .  7289062514901161E+000 

ACTUAL  DESTINATION  E15_WA04.2 

97 

98 

EXITING 

MSG_ID :  344 

LATENCY:  .  7289062514901161E+000 

ACTUAL  DESTINATION  F15_WA04 . 3 
97 

99 

EXITING 

MSG_ID :  344 

LATENCY:  .  7289062514901161E+000 

ACTUAL  DESTINATION  F15_WA04.4 
97 
100 

EXITING 

MSG_ID :  344 

LATENCY:  .  1291406251490116E+001 

ACTUAL  DESTINATION  F15_WA04 . Lead 

COMENCING  WITH  RECEPTION 

DESTINATION:  97 

RECEIVED  SAF  MESSAGE! 

EXPECTING  COMMUNICATION  WITH  RECEIVER  F15_WA04 . Lead 
FOUND  RECEIVER  IN  ENTITY  TABLE 

PUBLISHING  MSG  RECEIVED  HLA  INTERACTION 
SEND_SIM  PUB  MSG_RCVD . . . 

PUBLISHED  GIESIM  MSG  RCVD  INTERACTION 


First  the  details  of  the  received  GIESIM  MSG  SEND  HLA  interaction  are  displayed.  Then  the 
platform  look-up  functions  are  displayed.  In  this  case,  Entity  ID  18783  maps  to  SOF1  and 
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Entity  ID  29129  maps  to  the  lead  F15,  i.e.,  F15_WA04.Lead.  The  driven  JTIDS  system  then 
determines  if  an  Operational  Net  exists  with  (1)  the  SOF  as  transmitter,  (2)  the  lead  F15  as 
receiver,  and  (3)  with  Net  Type  14.  It  finds  Operational  Net  97,  and  then  sends  the  message  over 
the  simulated  JTIDS  Operational  Net.  When  F15_WA04.Lead  receives  the  message,  the  driven 
JTIDS  simulation  builds  a  GIESIMMSGRCVD  HLA  interaction,  and  sends  it.  (See  area  of 
Table  12  marked  in  blue.) 

The  left  side  of  Figure  48  shows  the  command  window  diagnostics  for  the 

GIESIM  MSG  RCVD  interaction  that  the  JTIDS  Driver  simulation  receives.  The  right  side  of 

Figure  48  shows  the  same  received  data  in  the  JTIDS  Driver  GUI  for  this  interaction. 


Command  Window  Diagnostics  for 
Received  GIESIM_MSG_RCVD  Interaction 


Received  GIESIM_MSG_RCVD  GUI  in 
JTIDS  Driver 


in  JTIDS  Driver 


RECV  INTERACTION  #  1  *** 

GIESIM_MSG_RCVD  INTERACTION  RECEIVED  AT  12100306 

FED_ID : .  0 

ENTITY_ID: .  29192 

RECV_MSG_ID: .  34  4 

RECV_SUM_LATENCY :  . 1291406E+001 

RECV  NET  ID: .  97 


A  MESSAGE  WAS  SUCCESSFULLY  SENT  OVER  NET:  97 

MESSAGE  ID:  344 

LATENCY:  . 1291406E+001 

MESSAGE  WAS  RECEIVED  BY  UNIT:  F15  WA04.Lead 


Figure  48  -  Diagnostic  for  Received  GIESIM  MSG  RCVD  Interaction 


5.8.3.3  Interoperability  Testing  Success 

The  enhanced  diagnostic  and  refinement  to  the  PSI  JTIDS  simulations  ultimately  helped  to 
resolve  some  minor  differences  in  FOM  interpretation  and  platform  referencing. 

PSI  sent  updated  versions  of  its  JTIDS  tools  to  both  SAIC  at  WPAFB  and  to  AFRL  Rome, 
where,  in  conjunction  with  updates  to  JSAF  made  by  SAIC,  interoperability  testing  was  finally 
completed  to  the  satisfaction  of  all  parties  involved. 
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6.0  CONCLUSIONS 


PSI  contributed  to  many  aspects  and  to  the  success  of  the  GIESim/JSB-RD  software  merger,  and 
was  a  consummate  and  proactive  team  player  throughout  the  project.  In  particular,  PSI  defined 
requirements  for  many  of  the  simulation  enhancements  that  are  required  in  JTIDS  and  in  JSAF. 
PSI  also  designed  and  developed  the  scenarios  used  in  the  merger.  As  presented  in  this  report, 
PSI  performed  requirements  analysis,  designed,  developed  and  tested  the  JTIDS  enhancements 
required  for  the  merger  of  the  GIESim  JTIDS  simulation  with  the  enhanced  version  of  JSAF. 

This  effort  heavily  leveraged  the  PSI  Link- 16  NMS  built  for  another  AFRL  team,  and  drew 
deeply  from  prior  experience  with  the  earlier  GIESim  projects. 

PSI  did  extensive  in-house  testing,  and  participated  in  the  extended  interoperability  tests  with 
JSAF  that  took  place  over  November  and  December.  PSI  also  supported  AFRL  leadership  by 
building  a  new,  more  robust,  and  supportable  version  of  the  GIESim  SAB  Demo,  and  worked 
with  SAIC  to  ensure  smooth,  successful  operation  of  the  standing  demo. 

PSI  looks  forward  to  expanding  on  the  GIESim/JSB-RD  merger  and  working  with  the  other  team 
members  and  AFRL  leadership  in  FY05  and  beyond.  The  accomplishments  of  the  merger 
software  bring  tactical  communications  modeling  to  JSAF,  which  is  critically  important  for 
evolving  Network  Centric  Operations  (NCO)  and  Warfare  (NCW). 

The  paper  retroactively  looks  back  over  the  FY04  effort  and  presents  Appendix  B  on  GIESim 
Contributions  to  GIESim/JSB-RD,  and  Appendix  C  lessons  learned.  The  remainder  of  this  paper 
looks  forward  to  future  work  and  includes  appendices  for  potential  near  term  (FY05)  work 
(Appendix  D)  and  further  out  work  (Appendix  E)  associated  with  the  merger. 

PSI  salutes  AFRL  leadership  for  their  vision  in  merging  the  GIESim  and  JSB-RD  efforts,  and 
would  like  to  express  our  appreciation  for  being  involved  in  the  3rd  year  of  the  GIESim  program. 
We  look  forward  to  a  continued  relationship  and  accomplishments  with  AFRL  Rome  programs 
and  projects. 
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APPENDIX  A  -  “WOW”  SCENARIO  DATA 


The  flight  path  data  for  the  F15  in  the  “Wow”  scenario  is  shown  in  Table  13  below.  Since  this 
data  will  be  imported  into  JSAF,  the  segment  speeds  of  200  MPS  shown  in  the  table  will  be 
replaced  by  segment  speeds  generated  by  JSAF.  A  graph  of  the  F15  flight  path  elevations  is 
shown  in  Figure  49,  and  its  profile  is  shown  in  Figure  50. 


Table  13  -  F15  "Wow”  Scenario  Flight  Path  Data 


Profile  Name 

Point 

# 

LAT 

LON 

ELEV 

(MASL) 

Speed 

MPS 

A04 W0W 

1 

39.08282 

124.89442 

10000 

200 

2 

39.32995 

125.24883 

8000 

200 

3 

39.54504 

125.53815 

5000 

200 

4 

39.66636 

125.70791 

2000 

200 

5 

39.74417 

125.89274 

1000 

200 

6 

39.83144 

125.98318 

400 

200 

7 

39.87886 

126.03476 

250 

200 

8 

39.92084 

126.06445 

200 

200 

9 

39.95814 

126.10066 

200 

200 

10 

39.99526 

126.13061 

150 

200 

11 

40.0498 

126.17883 

250 

200 

12 

40.13797 

126.11517 

1000 

200 

13 

40.13961 

125.8969 

2000 

200 

14 

40.10811 

125.47182 

5000 

200 

15 

40.01192 

125.117 

8000 

200 

16 

39.9443 

124.77702 

10000 

200 

17 

39.83639 

124.42457 

10000 

200 

Figure  49  -  Graph  of  F15  Flight  Path  Elevations  in  "Wow"  Scenario 
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FI  5  Flight  Path  Profile  in  "Wow"  Scenario 


LON 


Figure  50  -  F15  Flight  Path  Profile  in  "Wow"  Scenario 


Table  14  lists  the  data  for  the  UAV  flight  path  in  the  “Wow”  Scenario. 

Table  15  provides  the  data  for  the  positions  of  the  ground  elements,  i.e.,  SOF,  Target  and  Ground 
Threats,  in  the  “Wow”  Scenario. 

It  is  important  that  JSAF  preserves  the  integrity  of  the  F15  flight  path  waypoints  and  the  position 
of  the  SOF,  since  they  were  strategically  placed  such  that  communications  between  the  F15  and 
the  SOF  are  masked  by  terrain  when  the  F15  is  in  the  valley  leading  up  to  the  target. 
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Table  14  -  UAV  Flight  Data  for  "Wow"  Scenario 


Profile  Name 

Point 

# 

LAT 

LON 

LAT 

ELEV 

(MASL) 

Speed 

MPS 

UAV PATH 6 

1 

40.2177 

125.30674 

40.2177 

18000 

150 

2 

40.16243 

125.44003 

40.16243 

18000 

150 

3 

40.0505 

125.53255 

40.0505 

18000 

150 

4 

39.92676 

125.52621 

39.92676 

18000 

150 

5 

39.83817 

125.46509 

39.83817 

18000 

150 

6 

39.77087 

125.351 

39.77087 

18000 

150 

7 

39.76331 

125.16041 

39.76331 

18000 

150 

8 

39.82309 

125.04438 

39.82309 

18000 

150 

9 

39.91198 

124.95177 

39.91198 

18000 

150 

10 

40.07389 

124.94496 

40.07389 

18000 

150 

11 

40.16131 

125.01364 

40.16131 

18000 

150 

12 

40.20947 

125.11948 

40.20947 

18000 

150 

13 

40.21844 

125.30767 

40.21844 

18000 

150 

Table  15  -  Location  of  Ground  Elements  in  "Wow"  Scenario 


Platform  Name 

MGR 

Coord 

LAT 

LON 

ELEV 

(MAGL) 

SOF 1 

52TBK69378321 03 

40.00764 

126.29811 

5 

Target-wowl 

52TBK593453651 5 

40.04455 

126.17906 

0 

SAM_Popup 

52TBK5479936686 

40.04478 

126.12577 

0 

<-  antenna  height 
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APPENDIX  B  -  GIESIM  CONTRIBUTIONS  TO  JSAF 


Overarching  Contribution: 

Adds  realistic,  Link- 16  tactical  communication  modeling  to  JSAF.  Link- 16  is  the  preeminent 
tactical  data  link  in  use  today. 

Motivations: 

Today,  tactical  communications  are  critical  to  the  success  of  any  missions,  either  for  speed  of 
operations,  control,  situational  awareness  (SA),  reach-back,  and  for  prevention  of  fratricide. 
Joint  and  coalition  operations  and  the  modem  nature  and  OPTEMPO  of  war  today  make  the 
inclusion  of  communications  modeling  into  any  force-level  simulation  even  more  important. 

The  rapid  evolution  of  Network  Centric  Operations  (NCO)  and  Warfare  (NCW)  make  the 
inclusion  of  tactical  communications  model  even  more  important  to  JSAF. 

Attributes  and  Contributions  of  GIESim: 

•  Determination  and  visualization  of  radio  connectivity  including  impacts  of  terrain. 

•  Determination  and  visualization  of  network  connectivity  including  impacts  of  terrain  and 
relays. 

•  Add  realistic  communications  response  times,  throughput,  and  model  communication 
failure  cases. 

•  War  game  and  train  with  realistic  force  deployment  and  communications  scenarios. 

•  Measure  the  impact  of  communications  on  mission  success. 

•  Include  communications  planning  in  scenario  development  (and  operations  planning). 

•  Determine  points  of  failure  and  fix  them. 

•  Perform  what-if  analyses  on  tactical  networks. 

•  Allow  collaboration  between  mission  and  communications  planners. 

•  Optimize  deployment  of  assets  in  support  of  communications. 

•  Explore  communications  oriented  COAs  and  ECOAs,  e.g.,  impact  of  enemy  jamming  on 
communications  and  operations. 

•  GIESim  Team  Expertise:  The  team  has  three  years  of  experience  in  communications 
modeling  in  multi- simulation  environments.  We  have  experience  with: 

o  Force  deployment  scenario  development 
o  Communications  scenario  development 

o  Multi-simulation  interfacing  and  interoperability  via  HLA,  and  TCP/IP 
o  Tactical  radio  communications,  and  ground  network  modeling 
o  Rapid  development  and  re-use  of  communications  modeling 
o  Mission  Operations 

o  Adding  communications  modeling  to  force-level  simulations 
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APPENDIX  C  -  LESSONS  LEARNED 


This  section  overviews  some  of  the  lessons  learned  from  the  merger  of  GIESim  and  JSB-RD 
software  from  a  PSI  perspective.  There  is  value  in  having  team  collaboration  on  lessons  learned. 

•  It  is  an  order  of  magnitude  (or  more)  less  expensive  (in  time  and  dollars)  to  assemble  a 
multi-simulation  communications  capability  by  drawing  from  existing  models  and 
simulations. 

•  The  use  of  existing  models  and  simulations  does  not  eliminate  the  need  for  domain  or 
subject  matter  experts.  There  is  still  a  need  for  experts  to  define  and  develop  the  target 
analytical  system: 

o  Experts  in  the  models  and  simulation  environments  and  tools, 
o  Experts  in  the  systems  being  modeled. 

o  Expertise  in  reducing  system  needs  and  requirements  to  the  selection  of 
appropriate  models/simulations/ environments . 
o  Expertise  in  mission  operations  for  scenario  planning  and  development. 

•  While  are  is  high  value  in  the  models  and  interfaces  that  were  developed  to  realize  the 
“merger”,  there  is  equal  (perhaps  even  higher)  value  in  the  team  itself.  Members  of  the 
GIESim  team  have  been  together  for  three  years,  and  have  worked  closely  with  the  JSB- 
RD  team  for  the  past  year.  In  addition  to  developing  an  excellent  working  relationship 
with  high  mutual  respect,  we  have  also  fostered  the  building  of  expertise  developed 
through  living  through  building  of  the  GIESim  SAB  Demo,  and  through  resolving 
challenges  with  the  GIESim/JSB-RD  software  merger. 

•  Large  multi-forces  simulations  like  JSAF  are  extraordinarily  complex.  This  complexity, 
coupled  to  the  fact  that  they  do  not  inherently  model  communications,  makes  the  addition 
of  new  software  to  add  communications  hooks  and  behaviors  even  more  challenging. 
There  were  simply  conceptual  gulfs  that  the  team  had  to  overcome. 

•  Link- 16  tactical  communications  is  quite  complex  is  its  own  right.  In  retrospect,  the 
merger  of  GIESim  and  JSAF  would  have  benefited  from  wider  knowledge  of  Link- 16 
communications,  particularly  relay  capabilities.  As  our  software  migrates  into  use 
(hopefully)  by  JFCOM,  their  “mission  planners”  will  need  to  understand  capabilities  and 
limitations  of  Link- 16  platforms,  and  JFCOM  will  need  to  learn  about  Network  Planning 
and  Design.  This  is  particularly  important  since  the  network  design  will  need  to  change 
as  the  force  composition  varies  from  experiment  to  experiment. 

•  Simulation  interfacing  always  has  challenges.  For  GIESim  and  JSAF,  different  operating 
systems  (Windows  and  Linux)  introduced  some  (suspected)  added  complexity  and  made 
interoperability  testing  more  difficult,  particularly  since  we  couldn’t  run  JSAF  at  all 
locations.  Also,  the  use  RTI-S  made  interoperability  testing  over  the  Internet  essentially 
impossible,  and  necessitated  testing  of  components  at  one  or  more  locations.  Because  we 
“reused”  HLA  interactions  from  the  GIESim  SAB  Demo,  we  were  a  little  complacent 
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even  though  we  were  making  some  “minor”  changes  to  the  interaction.  In  general,  we 
need  to: 

o  Map  out  the  details  of  all  HLA  interactions  very  early  and  clearly  in  the  project. 

o  Ensure  that  all  parties  are  using  the  same  FOM  in  a  consistent  matter. 

•  Track  changes  more  carefully  as  system  components  evolve.  For  instance,  NET  TYPE 
NUMBERS  changed  from  the  early  values  specified  and  caused  some  minor  delays.. 

•  Model  requirements  and  multi-simulation  architecture  must  be  defined  based  on 
requirements  and  needs  of  the  target  analysis  that  is  to  be  accomplished.  Validity  should 
be  looked  at  as  a  quality  process  with  each  simulation/model  component  impacting 
quality  in  a  potentially  multiplicative  way. 

•  Existing  models  and  simulations  may  (and  probably  will)  need  tailoring  to  meet  the  needs 
of  the  each  experiment.  Thus,  a  simulation  environment  that  supports  ease  of  use  and 
understandability  is  essential.  Good  architectural  designs  are  also  needed. 

•  There  is  value  in  integrating  GIESim  and  JSAF  more  tightly,  particularly  in  the  area  of 
scenario  development.  The  PSI  Link- 16  Planning  Tool  is  excellent  for  building 
scenarios.  JSAF  has  its  own  scenario  building  capabilities.  A  more  effective  means  of 
exporting  and  importing  scenarios  between  these  tools  would  improve  efficiency  of 
scenario  development  and  incorporation  into  the  other  simulation  environment. 

•  Scenario  development  and  equipment  collections  must  be  defined  and  developed  for  the 
multi-simulation  environment  based  on  mission  needs  and  operations  being  planned. 

This  will  require: 

o  A  common  definition  of  what  is  meant  by  “scenario”. 

o  Import  of  terrain  for  area  of  interest. 

o  Flight  paths  and  other  movement  paths  for  dynamic  communications. 

o  Definition  and  implementation  of  network  characteristics  (connectivity,  network 
capabilities,  redundancies,  etc.). 

o  Traffic  generators  and  other  means  to  stimulate  the  simulation  environment  in 
realistic  ways. 

o  Many  other  variations  and  considerations  are  likely. 

•  Scenario  trade-offs  are  made  for  the  sake  of  a  demonstration  of  appropriate  length  - 
typically  5-10  minutes.  This  “marketing”  orientation  is  understandable,  although  it  may 
shift  attention  from  more  operationally  meaningful  scenarios  that  might  surface 
interoperability  problems  that  should  be  worked.  We  should  probably  test  robustness 
against  a  longer  running,  more  complex  scenario,  in  addition  to  a  demonstration  scenario 
targeted  for  an  audience. 

•  Potential  modifications  of  models  and  simulations  may  be  needed  as  identified  during 
testing  and  during  analytical  experiments,  e.g.,  need  to  have  the  ability  to  change  buffer 
sizes.  Ease  of  use  of  the  simulation  environment  is  critical  for  this. 
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Existing  models  and  simulations  may  (and  probably  will)  need  tailoring  to  meet  the  needs 
of  the  each  experiment.  Thus,  a  simulation  environment  that  supports  ease  of  use  and 
understandability  is  essential.  Good  architectural  designs  are  also  needed.  Some  points 
to  consider  include: 

o  Definition  and  development  of  IP  Interfaces,  and  HLA  interfaces  with  associated 
Interactions,  etc.,  with  of  IP  Addresses  and  required  simulation  and  entity  IDs. 
o  Definition  and  development  of  metrics  and  capabilities  to  collect  them,  e.g., 
latency.  These  metrics  may  require  new  models  or  tailoring  of  existing  model  to 
gather  and  report  to  the  multi-simulation  environment, 
o  Definition  and  development  of  means  to  interact  with  a  simulation  to  introduce 
controlled  flaws,  outages,  etc.  to  explore  overall  impacts  on  the  communications 
system  being  studied.  Means  might  include  real-time  feeds,  access  to  data  files, 
user  interaction  with  the  running  simulation,  and  multiple  simulation  runs, 
o  Definition  and  development  of  appropriate  visualization  capabilities  to  support 
both  testing  and  analytical  experiments. 


APPENDIX  D  -  PROPOSED  FY05  WORK 


The  success  of  the  GIESim/JSB-RD  software  merger  came  very  late  in  the  program.  As  such 
there  were  limited  opportunities  to  demonstrate  our  achievements  and  capabilities  to  audiences 
who  would  be  interested  in  leveraging  our  accomplishments.  Therefore,  a  rich  and  compelling 
demonstration  could  be  developed  to  showcase  our  work  and  to  solicit  further  developments. 

Also,  there  are  rich,  currently  untapped  opportunities  for  further  research  from  experiments  with 
our  system  to  explore  scalability,  more  complex  scenarios,  tighter  coupling  between  GIESim  and 
JSAF,  and  perhaps  new  modalities  for  operations. 

New  Demonstration  and  Presentation  Development 

The  FY05  Demonstration  of  the  merged  GIESim/JSB-RD  software  will  capitalize  on 
groundwork  and  capabilities  developed  in  FY04.  The  demonstration  will  be  aimed  at  audiences 
outside  of  AFRL  and  would  have  an  operationally  relevant,  and  high  impact  scenario  that  will 
show  the  full  capabilities  of  the  merged  software.  The  demonstration  will  be  easily  adapted  to 
the  technical  levels  of  the  audience,  ranging  from  no  technical  background  to  those  working  in 
the  network  modeling  and  simulation  area. 

This  task  will  have  several  subcomponents: 

•  Develop  a  scenario  for  the  demonstration. 

•  Implement  the  scenario. 

•  Develop  a  presentation  for  the  demonstration. 

•  Document  how  to  use  the  demonstration. 

•  Participate  in  the  demonstration. 

The  demonstration  will  in  part  be  based  on  the  “Wow”  scenario  that  was  suggested  and 
adopted  by  the  team  in  FY04,  and  selected  (and  potentially  expanded)  aspects  of  the  PSI  Korona 
scenario  that  PSI  shared  with  the  team  in  FY04.  Specific  scenario  details  will  be  developed  in 
conjunction  with  the  GIESim/JSB-RD  team. 

A  SOF  deployed  on  the  ground  detects  a  high-value  target,  and  sends  a  tasking  message 
to  the  FI 5  that  starts  to  ingress  towards  the  target.  As  the  FI 5  starts  to  follow  terrain  through  the 
valley,  the  SOF  sees  pop-up  threats,  and  sends  a  Threat  Warning  message  to  the  FI 5.  At  this 
point,  terrain  blocks  direct  reception  of  the  warning  message.  With  the  Global  Hawk  UAV 
acting  as  a  Link- 16  relay,  the  threat  warning  reaches  the  FI 5,  otherwise  the  F 15  continues  on 
towards  the  target  oblivious  to  the  threat. 


Experimentation  on  Merged  Software  &  Assess  Capabilities 

An  ultimate  goal  of  the  GIESim/JSB-RD  merger  is  to  add  tactical  communications  to 
JSAF  for  large  scenarios  through  distributed  simulation  with  the  PSI  Link- 16  Simulation 
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handling  the  tactical  data  links.  This  addition  to  JSAF  will  allow  the  JSB-RD  team  to  study  Air 
Force  platform  behaviors  they  are  adding.  This  task  will  involve: 

•  Expanded  scenarios:  Experiments  will  be  performed  as  the  scenario  size  increases. 
This  will  test  scalability  within  JSAF,  and  within  the  PSI  JTIDS  simulation,  and  with 
respect  to  HLA  RTI-S.  It  is  expected  that  the  PSI  Korona  force  deployment  scenario 
and  its  derivatives  will  play  a  key  role  in  scenarios  for  experimentation.  In  addition, 
the  JSB-RD  team  may  desire  to  add  specific  force  components  and  missions. 

•  Additional  Link-16  Network  Designs:  As  scenario  sizes  increase  there  will  be  a 
need  to  support  additional  Link- 16  message  traffic.  Specific  mission-related 
communications  requirements  for  the  GIESim/JSB-RD  scenarios  will  be  captured  in 
the  PSI  Link- 16  Planning  Tool,  and  then  the  actual  JTIDS/MIDS  time  slots  will  be 
allocated  automatically  by  the  PSI  TSA  tool.  Communications  requirements  need  to 
take  into  account  the  response  times,  addressability,  and  sizes  of  required  TADIL-J 
messages.  Increased  inter-platform  traffic  will  increase  the  load  on  the  JTIDS 
simulation,  and  this  is  one  focus  of  our  experimentation. 

•  Use  of  Multiple  Simulation  Configurations:  As  the  number  of  platforms  and 
associated  traffic  builds,  there  may  be  a  need  to  explore  the  use  of  multiple  simulation 
configurations.  It  may  be  possible  to  separate  platforms  into  isolated  communications 
groups  on  different  processors.  However,  the  desire  to  potentially  request 
transmission  of  PPLI  messages  between  platforms  may  impose  other  considerations. 

The  PSI  Korona  will  serve  as  part  of  the  basis  for  the  scenarios  that  evolve  for  the  demonstration 
and  experimentation. 
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APPENDIX  E  -  POTENTIAL  FUTURE  WORK 


This  appendix  is  forward  looking,  and  presents  some  ideas  on  future  work. 

Deeper  integration  of  GIESim  JTIDS  and  JSAF 

There  are  ample  opportunities  to  enrich  and  deepen  the  interface  and  integration  between  JSAF 
and  the  GIESim  JTIDS  simulation.  Some  ideas  follow. 

•  Additional  interactions:  The  current  interactions  are  bare  bones,  and  the  minimal  set 
required  for  JSAF  to  update  platform  positions  and  to  request  Link- 16  network  transmission. 
The  existing  HLA  interactions  could  be  enhanced  to  support  platform  health  and  other 
platform  and  communications  related  controls.  Transmission  requests  are  either  for  point- 
to-point  or  broadcast  (although  broadcast  has  not  be  used  nor  tested).  We  could  enrich  the 
HLA  destination  requests  to  make  use  of  Link- 16  message  addressing  capabilities. 

•  Creation  of  and  use  JFCOM  Mission  Threads:  Real  missions  have  a  certain  tempo,  and 
dynamic  relationships  between  participating  platforms  -  this  includes  communications. 
JFCOM  is  building  seven  “standard”  mission  threads  for  use  in  training  and  war  gaming. 

The  team  could  acquire  these  threads,  and  incorporate  them  into  our  scenarios  and  network 
designs. 

•  Use  of  platform  PPLI  and  Status  messages:  Link- 16  platforms  automatically  transmit 
location  and  platform  status  messages  to  enhance  situational  awareness  (SA)  and  to  avoid 
fratricide.  We  could  add  this  message  traffic  to  GIESim/JSAF. 

•  More  integrated  scenario  planning:  Currently  a  scenario  is  built  in  either  JTIDS  or  JSAF, 
then  “imported”  into  the  other  simulation  environment.  This  is  somewhat  awkward  and  time 
consuming.  Greater  use  of  Link- 16  Planning  and  network  design  capabilities  of  the  PSI  Link- 
16  NMS,  and  tighter  integration  with  JSAF  would  expedite  faster  and  more  comprehensive 
scenario  development. 

•  Investigate  support  for  24x7  operations:  JFCOM  is  moving  towards  24x7  operations  of 
large  distributed  simulations.  We  could  explore  how  to  do  this  in  conjunction  with  required 
network  designs. 

Support  for  and  Participation  in  one  or  more  operational  tests  and/or  events  in  05/06 

Now  that  the  team  has  integrated  GIESim  and  JSAF  to  support  tactical  data  links,  we  could  look 
to  participate  in  one  or  more  tests  using  JSAF.  This  would  get  us  operationally  connected,  and 
assist  us  in  better  understanding  how  exercises  are  planned  and  conducted.  It  would  also  be  an 
opportunity  to  input  our  requirements  for  tactical  communications  to  influence  future  planning 
by  users  of  JSAF. 
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Introduction  of  additional  tactical  data  links  and  networking  capabilities 

Looking  forward,  there  are  many  data  links  and  capabilities  that  could  be  added  to  JSAF  and 
similar  large-forces  simulations.  Some  potential  candidates  are  listed  below. 

o  Link- 1 1  HF/UHF:  After  Link- 16,  Link- 1 1  is  the  next  most  important  tactical  data 
link  (TDL). 

o  JTRS  WNW:  Joint  Tactical  Radio  System  (JTRS)  is  evolving,  and  will  offer 
software  controlled  versions  of  most  current  TDLs  including  Link- 16  and  Link-1 1. 

In  addition,  the  highly  touted  Wide  Band  Networking  Waveform  (WNW)  may 
become  an  important  capability  in  future  operations, 
o  Joint  Range  Extension  (JRE):  JRE  is  important  for  enabling  beyond-line-of-site 
(BLOS)  extension  of  Link- 16  between  separated  areas  of  interest.  JREs  can  bridge 
Link- 16  network  using  IP  networks  and  Satellite  connections, 
o  Satellites:  Satellite  play  and  increasingly  important  part  in  both  strategic  and  tactical 
communications,  as  well  as  intelligence. 

o  Ground  Networks:  All  military  operations  rely  on  some  form  of  ground  network,  and 
could  be  important  additions  to  JSAF  and  similar  systems, 
o  EW  Threats  (jammers,  etc.):  It  is  important  to  model  EW  threats  since  they  still  exist, 
and  can  greatly  impact  operations  at  critical  times. 

GIESim  Communications  modeling  for  other  JSAF-like  systems 

The  GIESim  Team  has  developed  considerable  expertise  in  merging  the  GIESim  JTIDS  software 
with  JSAF.  Furthermore,  we  have  built  a  sound  operational  framework  in  the  PSI  JTIDS 
simulation  to  easily  support  the  addition  of  Link- 16  tactical  communications  to  other  large  multi¬ 
forces  simulation.  This  is  something  the  AFRL  leadership  should  strongly  consider. 
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